SybasePowerDesigner rqug
Sybase®
PowerDesigner®
Requirements Model
User's Guide
Version 11.0
DC00121-01-1100-01
Last modified: November 2004
Copyright © 1991-2004 Sybase, Inc. All rights reserved.
Information in this manual may change without notice and does not represent a commitment on the part of Sybase, Inc. and its
subsidiaries.
Sybase, Inc. provides the software described in this manual under a Sybase License Agreement. The software may be used only in
accordance with the terms of the agreement.
No part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual,
optical, or otherwise, without the prior written permission of Sybase, Inc.
Use, duplication, or disclosure by the government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of DFARS 52.2277013 for the DOD and as set forth in FAR 52.227-19(a)-(d) for civilian agencies.
Sybase, SYBASE (logo), ADA Workbench, Adaptable Windowing Environment, Adaptive Component Architecture, Adaptive Server,
Adaptive Server Anywhere, Adaptive Server Enterprise, Adaptive Server Enterprise Monitor, Adaptive Server Enterprise Replication,
Adaptive Server Everywhere, Afaria, AppModeler, APT Workbench, APTBuild, APT-Edit, APT-Execute, APT-Translator, APTLibrary, ASEP, AvantGo, AvantGo Application Alerts, AvantGo Mobile Document Viewer, AvantGo Mobile Delivery, AvantGo
Mobile Inspection, AvantGo Mobile Marketing Channel, AvantGo Mobile Pharma, AvantGo Mobile Sales, AvantGo Pylon, AvantGo
Pylon Application Server, AvantGo Pylon Conduit, AvantGo Pylon PIM Server, AvantGo Pylon Pro, Backup Server, BayCam, BitWise, BizTracker, Certified PowerBuilder Developer, Certified SYBASE Professional, Certified SYBASE Professional Logo,
ClearConnect, Client-Library, Client Services, CodeBank, Column Design, ComponentPack, Connection Manager, Convoy/DM,
Copernicus, CSP, Data Pipeline, Data Workbench, DataArchitect, Database Analyzer, DataExpress, DataServer, DataWindow, DBLibrary, dbQueue, Developers Workbench, Direct Connect Anywhere, DirectConnect, Distribution Director, Dynamic Mobility Model,
e-ADK, E-Anywhere, e-Biz Integrator, E-Whatever, EC Gateway, ECMAP, ECRTP, eFulfillment Accelerator, Electronic Case
Management, Embedded SQL, EMS, Enterprise Application Studio, Enterprise Client/Server, Enterprise Connect, Enterprise Data
Studio, Enterprise Manager, Enterprise Portal (logo), Enterprise SQL Server Manager, Enterprise Work Architecture, Enterprise Work
Designer, Enterprise Work Modeler, eProcurement Accelerator, eremote, Everything Works Better When Everything Works Together,
EWA, Financial Fusion, Financial Fusion (and design), Financial Fusion Server, Formula One, Fusion Powered e-Finance, Fusion
Powered Financial Destinations, Fusion Powered STP, Gateway Manager, GeoPoint, GlobalFIX, iAnywhere, iAnywhere Solutions,
ImpactNow, Industry Warehouse Studio, InfoMaker, Information Anywhere, Information Everywhere, InformationConnect, InstaHelp,
Intelligent Self-Care, InternetBuilder, iremote, iScript, Jaguar CTS, jConnect for JDBC, KnowledgeBase, Logical Memory Manager,
M-Business Channel, MBusiness Network, M-Business Server, Mail Anywhere Studio, MainframeConnect, Maintenance Express,
Manage Anywhere Studio, MAP, MDI Access Server, MDI Database Gateway, media.splash, Message Anywhere Server, MetaWorks,
MethodSet, ML Query, MobiCATS, My AvantGo, My AvantGo Media Channel, My AvantGo Mobile Marketing, MySupport, NetGateway, Net-Library, New Era of Networks, Next Generation Learning, Next Generation Learning Studio, O DEVICE, OASiS,
OASiS logo, ObjectConnect, ObjectCycle, OmniConnect, OmniSQL Access Module, OmniSQL Toolkit, Open Biz, Open Business
Interchange, Open Client, Open ClientConnect, Open Client/Server, Open Client/Server Interfaces, Open Gateway, Open Server, Open
ServerConnect, Open Solutions, Optima++, Orchestration Studio, Partnerships that Work, PB-Gen, PC APT Execute, PC DB-Net, PC
Net Library, PhysicalArchitect, Pocket PowerBuilder, PocketBuilder, Power++, Power Through Knowledge, power.stop, PowerAMC,
PowerBuilder, PowerBuilder Foundation Class Library, PowerDesigner, PowerDimensions, PowerDynamo, Powering the New
Economy, PowerScript, PowerSite, PowerSocket, Powersoft, PowerStage, PowerStudio, PowerTips, Powersoft Portfolio, Powersoft
Professional, PowerWare Desktop, PowerWare Enterprise, ProcessAnalyst, QAnywhere, Rapport, Relational Beans, RemoteWare,
RepConnector, Report Workbench, Report-Execute, Replication Agent, Replication Driver, Replication Server, Replication Server
Manager, Replication Toolkit, Resource Manager, RW-DisplayLib, RW-Library, SAFE, SAFE/PRO, SDF, Secure SQL Server, Secure
SQL Toolset, Security Guardian, SKILS, smart.partners, smart.parts, smart.script, SQL Advantage, SQL Anywhere, SQL Anywhere
Studio, SQL Code Checker, SQL Debug, SQL Edit, SQL Edit/TPU, SQL Everywhere, SQL Modeler, SQL Remote, SQL Server, SQL
Server Manager, SQL SMART, SQL Toolset, SQL Server/CFT, SQL Server/DBM, SQL Server SNMP SubAgent, SQL Station, SQLJ,
Stage III Engineering, Startup.Com, STEP, SupportNow, S.W.I.F.T. Message Format Libraries, Sybase Central, Sybase Client/Server
Interfaces, Sybase Development Framework, Sybase Financial Server, Sybase Gateways, Sybase IQ, Sybase Learning Connection,
Sybase MPP, Sybase SQL Desktop, Sybase SQL Lifecycle, Sybase SQL Workgroup, Sybase Synergy Program, Sybase Virtual Server
Architecture, Sybase User Workbench, SybaseWare, Syber Financial, SyberAssist, SybFlex, SybMD, SyBooks, System 10, System 11,
System XI (logo), SystemTools, Tabular Data Stream, The Enterprise Client/Server Company, The Extensible Software Platform, The
Future Is Wide Open, The Learning Connection, The Model For Client/Server Solutions, The Online Information Center, The Power of
One, TotalFix, TradeForce, Transact-SQL, Translation Toolkit, Turning Imagination Into Reality, UltraLite, UltraLite.NET, UNIBOM,
Unilib, Uninull, Unisep, Unistring, URK Runtime Kit for UniCode, Viewer, VisualWriter, VQL, WarehouseArchitect, Warehouse
Control Center, Warehouse Studio, Warehouse WORKS, Watcom, Watcom SQL, Watcom SQL Server, Web Deployment Kit,
Web.PB, Web.SQL, WebSights, WebViewer, WorkGroup SQL Server, XA-Library, XA-Server, XcelleNet, and XP Server are
trademarks of Sybase, Inc. or its subsidiaries.
All other trademarks are property of their respective owners.
Contents
About This Book
...........................................................................................vii
1
Requirements model basics..............................................1
Functional overview .................................................................. 2
What is a requirements model?................................................ 4
Objects in a requirements model ....................................... 5
Defining the requirements model environment ......................... 6
Selecting extended model definitions at model creation .... 6
Defining model options....................................................... 8
Requirements model extended dependencies................. 10
Defining a requirements model............................................... 11
Defining model properties ................................................ 11
Creating a requirements model........................................ 14
Opening an existing requirements model......................... 18
Detaching a requirements model from the workspace..... 18
Saving and closing a requirements model ....................... 19
Defining packages in a requirements model .......................... 20
Requirements package properties ................................... 21
Creating a requirements package .................................... 24
2
Building a requirements model.......................................25
Defining requirements views................................................... 26
Why views instead of diagrams?...................................... 26
Requirements views properties ........................................ 27
Defining requirements document views ........................... 28
Defining traceability matrix views ..................................... 32
Creating a requirements view........................................... 40
Defining requirements............................................................. 45
Defining requirements properties ..................................... 45
Creating a requirement..................................................... 55
Defining users and groups ...................................................... 57
Creating a user or a group ............................................... 57
User general properties.................................................... 58
Group general properties ................................................. 58
Attaching users and groups to a group ............................ 59
Defining glossary terms .......................................................... 60
Requirements Model User's Guide
iii
Glossary term general properties ..................................... 60
Creating a glossary term .................................................. 61
Using design objects............................................................... 62
Defining business rules........................................................... 63
What is a business rule? .................................................. 63
Activating business rules in a requirements model .......... 63
Defining business rules properties ................................... 66
Creating a business rule................................................... 67
Applying a business rule to a requirement ....................... 69
3
Working with a requirements model .............................. 71
Checking a requirements model............................................. 72
Defining options in Check Model...................................... 72
Selecting objects in Check Model .................................... 73
Checking a requirements model ...................................... 73
Displaying previously applied check options in a
requirements model ......................................................... 76
Making corrections based on requirements model check
results............................................................................... 76
Requirements model objects verified by Check Model........... 79
Business rule check ......................................................... 79
Glossary term check ........................................................ 80
User check ....................................................................... 80
Group check ..................................................................... 81
Requirement check .......................................................... 82
File check ......................................................................... 83
Extended object check ..................................................... 84
Extended link check ......................................................... 84
Replication check ............................................................. 84
Comparing and merging requirements models ...................... 85
Linking requirements with design objects ............................... 86
Attaching design objects to requirements ........................ 86
Attaching requirements to design objects ........................ 89
Exporting requirements as design objects.............................. 95
Importing design objects as requirements.............................. 99
4
Using MS Word with a requirements model ................ 103
Creating a requirements model from an MS Word
document .............................................................................. 106
Importing an MS Word document as a requirements
model.............................................................................. 106
Using MS Word to create a requirements model ........... 109
How are a model and a document linked?..................... 112
Creating a requirement from a selected text ........................ 117
iv
PowerDesigner
Creating an MS Word document from a requirements
model .................................................................................... 121
Inserting a requirements model into an existing MS Word
document .............................................................................. 124
Updating an MS Word document from a requirements
model .................................................................................... 127
Updating a requirements model from an MS Word
document .............................................................................. 129
Detaching an MS Word document from a requirements
model .................................................................................... 133
Detaching a requirements model from an MS Word
document .............................................................................. 135
Requirements Model Glossary ........................................................................137
Index
.........................................................................................139
Requirements Model User's Guide
v
vi
PowerDesigner
About This Book
Subject
Audience
This book describes the PowerDesigner Requirements Model environment. It
shows you how to do the following:
♦
Create requirements document views
♦
Create traceability matrix views
♦
Define specific objects in a requirements model
♦
Check a requirements model
♦
Compare and merge requirements models
♦
Link requirements with design objects (objects from other types of
models)
♦
Export requirements as design objects
♦
Import design objects as requirements
♦
Create and update an MS Word document from a requirements model
♦
Insert a requirements model into an existing MS Word document
♦
Create and update a requirements model from an MS Word document
This book is for anyone who wants to build a requirements model with
PowerDesigner. It does not require any particular knowledge. For more
information, see the Bibliography section at the end of this chapter.
Requirements Model User's Guide
vii
About This Book
Documentation
primer
The PowerDesigner modeling environment supports several types of models:
♦
Conceptual Data Model (CDM) to model the overall logical structure
of a data application, independent from any software or data storage
structure considerations
♦
Physical Data Model (PDM) to model the overall physical structure of
a database, taking into account DBMS software or data storage structure
considerations
♦
Object Oriented Model (OOM) to model a software system using an
object-oriented approach for Java or other object languages
♦
Business Process Model (BPM) to model the means by which one or
more processes are accomplished in operating business practices
♦
XML Model (XSM) to model the structure of an XML file using a DTD
or an XML schema
♦
Requirements Model (RQM) to list and document the customer needs
that must be satisfied during a development process
♦
Information Liquidity Model (ILM) to model the replication of
information from a source database to one or several remote databases
using replication engines
♦
Free Model (FEM) to create any kind of chart diagram, in a contextfree environment
This book only explains how to use the Requirements Model. For
information on other models or aspects of PowerDesigner, consult the
following books:
General Features Guide
To get familiar with the PowerDesigner
interface before learning how to use any of the models.
Conceptual Data Model Getting Started To learn the basics of the
CDM.
Conceptual Data Model User’s Guide
To work with the CDM.
Physical Data Model Getting Started
Physical Data Model User’s Guide
To learn the basics of the PDM.
To work with the PDM.
Object Oriented Model Getting Started
OOM.
Object Oriented Model User's Guide
viii
To learn the basics of the
To work with the OOM.
PowerDesigner
About This Book
Business Process Model Getting Started
To learn the basics of the
BPM.
Business Process Model User’s Guide
XML Model User’s Guide
To work with the BPM.
To work with the XSM.
Information Liquidity Model User’s Guide
Reports User’s Guide
To work with the ILM.
To create reports for any or all models.
Repository Getting Started
Repository User’s Guide
To learn the basics of the Repository.
To work in a multi-user environment using a
central repository.
Typographic
conventions
PowerDesigner documentation uses specific typefaces to help you readily
identify specific items:
♦
monospace text (normal and bold)
Used for: Code samples, commands, compiled functions and files,
references to variables.
Example: declare user_defined…, the
BeforeInsertTrigger template.
♦
UPPER CASE
Object codes, reversed objects, file names + extension.
Example: The AUTHOR table appears in the Browser. Open the file
OOMAFTER.OOM.
♦
bold text
Any new term.
Example: A shortcut has a target object.
♦
SMALL CAPS
Any key name.
Example: Press the ENTER key.
Bibliography
INCOSE (International Council on Systems Engineering) –
http://www.incose.org/practice/techactivities/semanagement/rwg.aspx
Special thanks to Dr Gregory Abowd and his team, Jeffrey Corn (Manager),
Travis Works (Architect), John Garrard (Programmer), Kesniel Acton
(Technical Writer), and Dinesh Krishna (Quality Assurance), who designed
the CyberFridge project – Copyright 2004, Georgia Tech Research
Corporation, Atlanta, Georgia 30332-0415, All Rights Reserved
Requirements Model User's Guide
ix
About This Book
x
PowerDesigner
C H A P T E R
1
Requirements model basics
About this chapter
Contents
This chapter presents the PowerDesigner Requirements Model. It provides
you with an introduction to the basic notions of the Requirements Model.
Topic
Page
Functional overview
2
What is a requirements model?
4
Defining the requirements model environment
6
Defining a requirements model
11
Defining packages in a requirements model
20
Requirements Model User's Guide
1
Functional overview
Functional overview
The Requirements Model (RQM) is a documentary model. It describes a
project by listing and explaining precisely what actions must be implemented
during a development process.
You can use the Requirements Model for any kind of structured technical
document (e.g. functional or technical specification, test plan) that must be
taken into account during a development process.
The Requirements Model displays no diagram but two different kinds of
views:
♦
Requirements document views: numbered lists of requirements with a
common set of properties
♦
Traceability matrix views: grids indicating the links between current
requirements and design objects (objects from other types of models),
external files or other requirements
For more information on requirements views, see section Defining
requirements views, in chapter Building a requirements model.
The Requirements Model allows you to:
♦
Build a requirements model from a structured technical document
♦
Check an existing or imported model
♦
Create links between requirements and design objects (objects from
other types of models)
♦
Create requirements from design objects, and vice versa
Some design objects (e.g. business rules, packages, use cases) may
correspond to requirements, and vice versa
♦
Create and update an MS Word document from a requirements model
To provide users with an MS Word document corresponding to the
requirements model
♦
Create and update a requirements model from an MS Word document
To start from an existing MS Word document
2
PowerDesigner
Chapter 1
Requirements model basics
From a requirements model, you can create design objects from
requirements, or create and update an MS Word document.
You can also create requirements from design objects, or create and update a
requirements model from an MS Word document.
Requirements Model User's Guide
3
What is a requirements model?
What is a requirements model?
A requirements model is a documentary model that helps you list and define
precisely what actions must be implemented during a development process.
Requirements are listed in document views, and their links with design
objects (objects from other types of models), external files or other
requirements are managed in traceability matrix views.
A requirements model sets and reminds what is at stake and what must be
done during a development process.
A requirements model is the reference model which defines the tasks and
orientates the work of all users and groups involved in a development
process.
Example of a requirements model (Browser and requirements document
view):
Demo models
Demo requirements models are available in the Examples directory.
4
PowerDesigner
Chapter 1
Requirements model basics
Objects in a requirements model
A requirements model has some specific objects:
Object
Description
Requirement
The name and description of an action. It can be
part of a hierarchy with parent and child
requirements. It must be defined precisely before
being assigned to users and groups
Glossary term
A word used in a requirements model. It must be
defined precisely to avoid misunderstandings and
set a common vocabulary
User
A person that is concerned by at least one
requirement
Group
A group of users that have a common interest in
satisfying at least one requirement
None of these objects has a graphic symbol, since there are no diagrams in a
requirements model. Requirements are listed in document views. Traceability
matrix views display the links between requirements and design objects
(objects from other types of models), external files or other requirements.
All objects appear in the Browser tree view.
Requirements Model User's Guide
5
Defining the requirements model environment
Defining the requirements model environment
The requirements model environment includes a set of parameters and
configuration options that define various aspects of the model content and
behavior. You can set these parameters:
♦
At model creation
♦
After creating a model with default options and parameters
♦
When creating a model template
Selecting extended model definitions at model creation
Extended model definitions (.XEM files) provide means for customizing and
extending PowerDesigner metaclasses, parameters and generation. Extended
model definitions are typed like models in PowerDesigner. You create an
extended model definition for a specific type of model and you cannot share
these files between heterogeneous models.
In the case of requirements models, you can use extended model definitions
as methodological supports for requirements management:
♦
Custom checks verify that methodological statements are satisfied. For
example, each requirement of scenario type must be associated with a
use case in an OOM
♦
You can customize the list of values for some properties. See Detail
properties, in Defining requirements properties, in chapter Building a
requirements model
♦
You can initialize the default values of a requirement, just after its
creation, by using the Initialize event handler
When you create a new requirements model, you can select one or several
extended model definitions and attach them to the model from the New
dialog box.
6
PowerDesigner
Chapter 1
Requirements model basics
You can choose one of the following options:
Option
Description
Share
Current extended model definition constantly refers to the extended
model definition stored in the Resource Files\Extended Model
Definitions directory. Any changes made to the extended model
definition are shared by all linked XEM
Copy
Current extended model definition is a unique copy of the extended
model definition stored in the Resource Files\Extended Model
Definitions directory. The current extended model definition is
independent of the original one, so modifications made to the
extended model definition in the Resource Files\Extended Model
Definitions directory are not available to the copied XEM. This one
is saved with the requirements model and cannot be used without it
For more information on extended model definitions, see chapter
Extended Model Definitions Reference Guide, in the Advanced User
Documentation.
Requirements Model User's Guide
7
Defining the requirements model environment
Defining model options
You can define the following options for a requirements model:
♦
Name/Code case sensitivity
♦
Title fonts
♦
Naming conventions
To define requirements model options:
1
In the menu bar, select Tools→Model Options.
The Model Options dialog box appears.
8
2
Select a category in the left pane and define its properties in the right
part of the dialog box.
3
Click OK.
PowerDesigner
Chapter 1
Requirements model basics
Name/Code case sensitivity
You can define the case sensitivity of names and codes for all objects in the
current model. When this check box is selected, it implies that you can have
two objects with identical name or code but different case in the same
namespace. You can modify the name and code case sensitivity during the
design process. However, if you do so, make sure you run the check model
feature to verify if the model does not contain any duplicate object.
Title fonts
You can define title fonts for requirements document views.
To define title fonts in Model Options:
1
Select a title level in the Title level pane.
2
Define the characteristics of the title level in the other panes.
3
Repeat steps 1 and 2 for each title level you want to modify.
4
Click OK.
The title fonts appear in the current document view as defined in the
Model Options dialog box.
Requirements Model User's Guide
9
Defining the requirements model environment
Naming conventions
You can also set naming conventions for each type of objects in your model.
For information on naming conventions, see section Defining naming
conventions, from chapter Managing Models, in the General Features Guide.
Requirements model extended dependencies
Extended dependencies are links between objects of a requirements model.
These links help to make object relationships clearer but are not interpreted
and checked by PowerDesigner, as they are meant to be used for
documentation purposes only.
You can complement these links by applying stereotypes. Stereotypes can be
used to define extended dependencies between objects in a requirements
model.
You can type stereotypes directly in the Stereotype column of the object
property sheet or select a value from the dropdown listbox, if you have
previously defined stereotypes in an embedded or imported extended model
definition (.XEM).
For more information on extended model definitions, see chapter
Extended Model Definitions Reference Guide in the Advanced User
Documentation.
10
PowerDesigner
Chapter 1
Requirements model basics
Defining a requirements model
This section presents the main operations you have to perform before starting
to build or work on a requirements model.
Defining model properties
The model property sheet displays the definition of the current model.
This section only explains the specific pages of a requirements model
property sheet.
For more information on the generic pages of a model property sheet,
see section Using property sheets in chapter Using the PowerDesigner
Interface, in the General Features Guide.
To define the properties of a requirements model:
1
Select Model→Model Properties.
or
Right-click the model name or icon in the Browser, and select Properties
in the contextual menu.
The model property sheet appears.
2
Define model properties in the different pages.
Requirements Model User's Guide
11
Defining a requirements model
3
Click OK.
Model General page
The General page of a requirements model property sheet displays the
following properties:
Property
Description
Name
Name of the model
Code
Code of the model
Comment
Descriptive label of the model
File name
Location of the model file. This box is empty if the model has
never been saved
Author
Author of the model. You can insert a name, a space or
nothing. If you insert a space, the Author field in the title box
remains empty. If you intentionally leave the box empty, the
Author field in the title box displays the user name from the
Version Info page of the model property sheet
Version
Version of the model. You can use this box to display the
repository version or a user-defined version of the model.
This parameter is defined in the display preferences of the
Title node
Default view
View displayed by default when opening the model
Model Detail page
The Detail page of a requirements model property sheet displays the
following properties:
Property
Description
Workload 1
Sum of all the workloads assigned to a first person or team
Workload 2
Sum of all the workloads assigned to a second person or team
Workload 3
Sum of all the workloads assigned to a third person or team
Workload 4
Sum of all the workloads assigned to a fourth person or team
A workload is the time assigned to a person or a team to satisfy a
requirement. This time is divided by as many persons in the team. You
should respect a unit for all workloads (hour or day). Values must be greater
or equal to zero, and limited to one decimal (For example: 3.5).
12
PowerDesigner
Chapter 1
Requirements model basics
A parent requirement workload is the sum of its child requirements
workloads. Parent workloads are automatically calculated once you enter
their child workloads. Model workloads are the sum of all child workloads.
Model and parent workloads are in read-only mode (grayed). You can only
modify child workloads.
Traceability Links page
To help understanding a requirements model or package, you can create links
with design objects (objects from other types of models) and external files
(MS Word, MS Excel, PowerDesigner...).
Use the following tools to create links with the current model or package:
Tool
Tooltip
Description
Add Links to Design Objects
Creates shortcuts to attach design
objects to the current model or
package. Design objects are selected
from design models open in the
workspace
Add Link to External File
Creates a link between an external file
(whatever the format) and the current
model or package. The external file is
stored in a Files folder within the
model
The standard Traceability Links page displays the following properties:
Property
Description
Linked Object
Design objects or external files linked to the requirements
model or package
Bookmark
Bookmark for the MS Word file linked with the requirements
model or package. Click a cell, then the Ellipsis button (…)
to create or modify a bookmark.
See Defining a bookmark for an MS Word file, in Defining
requirements properties, in chapter Building a requirements
model
You can modify the properties displayed in the Traceability Links page by
clicking the Customize Columns and Filter tool.
Requirements Model User's Guide
13
Defining a requirements model
Creating a requirements model
There are several ways to create a requirements model:
♦
Create a new requirements model
♦
Create a new requirements model using a template
♦
Create a new requirements model importing an MS Word document. See
Importing an MS Word document as a requirements model, in chapter
Using MS Word with a requirements model
Creating a requirements model using the New model option
When you create a requirements model using the New model option, an
Extended Model Definitions page appears.
The following options concern extended model definitions that you would
have selected:
14
Option
Description
Share
To use the shared extended model definitions stored in the Extended
Model Definitions directory of your installation. Any changes made
to the extended model definitions are available to the linked
requirements model
Copy
To create a copy of the extended model definition in the model. The
current extended model definition is independent from the original
extended model definition, so any changes made in the extended
model definition are not available to other models. The extended
model definition is saved with the model and cannot be used by
other models
PowerDesigner
Chapter 1
Requirements model basics
To create a new requirements model using the New model option:
1
In the menu bar, select File→New.
The New dialog box appears.
2
Select Requirements Model in the list of model types.
3
Select the New model radio button in the upper right part of the dialog
box.
4
If you want to attach one or more extended model definitions
to the model, select the extended model definitions of your choice in the
Extended Model Definitions page.
For more information on attaching extended model definitions to a
model, see section Selecting extended model definitions at model
creation.
5
Select either Share or Copy the extended model definitions.
Requirements Model User's Guide
15
Defining a requirements model
6
Click OK.
A new requirements model is created in the Workspace (Browser and
document view).
7
Select Model→Model Properties.
The model property sheet appears.
16
8
Type a name and a code for the model.
9
Click OK.
PowerDesigner
Chapter 1
Requirements model basics
Creating a requirements model using the New model from template option
To create a new requirements model using the New model from
template option:
1
Select File→New to display the New dialog box.
2
Select Requirements Model in the list of model types.
3
Select the New model from template radio button, in the upper right
part of the dialog box, to display the Template page.
4
Select a model template from the list.
List of templates
You can select user-defined model templates (use the Change userdefined model templates folder tool to specify the user templates
folder) and copy some existing models as model templates using the
Copy model to user-defined model templates folder tool.
For more information on model templates, see section Creating a
model, in chapter Managing Models, in the General Features Guide.
5
Click OK.
A new requirements model is created in the Workspace.
6
Select Model→Model Properties.
The model property sheet appears.
Requirements Model User's Guide
17
Defining a requirements model
7
Type a name and a code for the model.
8
Click OK.
Opening an existing requirements model
A requirements model has the file extension .RQM.
To open an existing requirements model:
1
Select File→Open.
or
Click the Open tool.
A standard Windows Open file dialog box appears.
2
Select a file with a .RQM extension.
3
Click Open.
The existing model appears in the workspace.
Detaching a requirements model from the workspace
When you detach a requirements model from a workspace, its node is
removed from the Browser, and it is no longer defined in the workspace. Yet
the file is not deleted from your operating environment.
To detach a requirements model from a workspace:
1
Right-click the requirements model node in the Browser and select
Detach from Workspace in the contextual menu.
A confirmation box asks if you want to save the requirements model.
2
Click Yes, if you want to save modifications to the requirements model.
Select or browse to a directory.
Type a name for the file and click the Save button.
or
Click No, if you do not want to save modifications to the file.
The requirements model is removed from the workspace.
18
PowerDesigner
Chapter 1
Requirements model basics
Saving and closing a requirements model
Saving a
requirements
model
To save a requirements model, choose one of the following options:
♦
Select File→Save
♦
Click the Save tool in the standard toolbar
♦
Right-click the requirements model in the Browser, and select Save in
the contextual menu
If it is the first time you save a requirements model, a standard Windows
Save As dialog box appears: Type a file name, choose a folder in your
directory and click Save.
Closing a
requirements
model
To close a requirements model, choose one of the following options:
♦
Select File→Close
♦
Right-click the requirements model in the Browser, and select Close in
the contextual menu
When a requirements model is closed, a red mark appears on its icon in the
Browser:
Requirements Model User's Guide
19
Defining packages in a requirements model
Defining packages in a requirements model
A package is a piece of a model.
When working with a large model, you can split the model into smaller
subdivisions to avoid manipulating the entire set of model objects. Packages
can be useful to assign portions of a model, representing different tasks and
subject areas, to different development teams.
In the following example, a package contains functional requirements and
another package contains non-functional requirements.
Package hierarchy
You can create several packages at the same hierarchical level within a
model, or decompose a package into other packages, and continue this
process without limitation in decomposition depth. Each package appears
with a default requirements view (document or matrix view). At each level of
decomposition, you can create several requirements views.
To display a package view, you must double-click its name or icon in the
Browser tree view.
For more information on packages, see the section Defining a package
in the General Features Guide.
Package
requirements
20
In a requirements model, packages only appear in the Browser tree view. To
add requirements to a package, you can:
♦
Create requirements directly from the package document view(s)
♦
In the Browser, select requirements from the model Requirements folder,
and drag and drop them either in the package document view(s) or
beneath the package Requirements folder (for root requirements), or
beneath other requirements (for child requirements)
PowerDesigner
Chapter 1
Requirements model basics
You can link requirements from different packages of the same model. Use
the Add Links to Other Requirements tool, in the Traceability Links page
of the requirements property sheet.
Requirements package properties
This section explains the specific pages of a requirements package property
sheet.
For more information on the generic pages of a property sheet, see
section Using property sheets in chapter Using the PowerDesigner Interface,
in the General Features Guide.
To display a package property sheet:
♦
Double-click its name or icon in the Browser
♦
Right-click its name or icon in the Browser, and select Properties in the
contextual menu
Package General page
The General page of a package property sheet displays the following
properties:
Property
Description
Name
Name that clearly identifies the package
Code
Codes are references for packages
Comment
Optional label that describes a package and provides additional
information
Stereotype
Sub-classification used to extend the semantics of an object without
changing its structure. It can be predefined or user-defined
Use parent
namespace
Defines the package as being the area in which the name of an
object must be unique in order to be used. The package is the
default namespace
Default view
View displayed by default when you open the package
Requirements Model User's Guide
21
Defining packages in a requirements model
Package Detail page
The Detail page of a package property sheet displays the following
properties:
Property
Description
Workload 1
Sum of all the workloads assigned to a first person or team to
satisfy all the requirements of the current package
Workload 2
Sum of all the workloads assigned to a second person or team
to satisfy all the requirements of the current package
Workload 3
Sum of all the workloads assigned to a third person or team to
satisfy all the requirements of the current package
Workload 4
Sum of all the workloads assigned to a fourth person or team to
satisfy all the requirements of the current package
A workload is the time assigned to a person or a team to satisfy a
requirement. This time is divided by as many persons in the team. You
should respect a unit for all workloads (hour or day). Values must be greater
or equal to zero, and limited to one decimal (For example: 3.5).
A parent requirement workload is the sum of its child requirements
workloads. Parent workloads are automatically calculated once you enter
their child workloads. Package workloads are the sum of all their child
workloads. Package, sub-package and parent workloads are in read-only
mode (grayed). You can only modify child workloads.
22
PowerDesigner
Chapter 1
Requirements model basics
Traceability links page
To help understanding a requirements package or model, you can create links
with design objects (objects from other types of models) and external files
(MS Word, MS Excel, PowerDesigner...).
Use the following tools to create links with the current package or model:
Tool
Tooltip
Description
Add Links to Design Objects
Creates shortcuts to attach design
objects to the requirements package or
model. Design objects are selected
from design models open in the
workspace
Add Link to External File
Creates a link between an external file
(whatever the format) and the
requirements package or model. The
external file is stored in a Files folder
within the model
The standard Traceability Links page displays the following properties:
Property
Description
Linked Object
Design objects or external files linked to the requirements
package or model
Bookmark
Bookmark for the MS Word file linked with the requirements
package or model. Click a cell, then the Ellipsis button (…)
to create or modify a bookmark.
See Defining a bookmark for an MS Word file, in Defining
requirements properties, in chapter Building a requirements
model
You can modify the properties displayed in the Traceability Links page by
clicking the Customize Columns and Filter tool.
Requirements Model User's Guide
23
Defining packages in a requirements model
Creating a requirements package
You can create a requirements package using the following methods:
♦
Right-click the model item in the Browser, and select New→Package in
the contextual menu. A root package (directly linked to the model item)
is created
♦
Right-click a package item in the Browser, and select New→Package in
the contextual menu. A sub-package is created under the selected
package
♦
Use the List of Packages in the Model menu
To create a requirements package using the List of Packages:
1
In the menu bar, select Model→Packages.
The List of Packages appears.
If the model document view is open in the workspace, the List of
Packages displays the root packages of the model.
If a package document view is open in the workspace, the List of
Packages displays the sub-packages of the current package.
2
Click a blank line in the list.
A package appears in the list, with generic name and code.
3
Type a name and a code for the package.
4
Click OK.
The new package appears in the Browser tree view as a root package or
a sub-package.
To display a package view, double-click its name or icon in the Browser.
24
PowerDesigner
C H A P T E R
2
Building a requirements model
About this chapter
Contents
This chapter describes how to build a requirements model (RQM). It explains
the role of each object in a requirements model and how to create them.
Topic
Page
Defining requirements views
26
Defining requirements
45
Defining users and groups
57
Defining glossary terms
60
Using design objects
62
Defining business rules
63
Requirements Model User's Guide
25
Defining requirements views
Defining requirements views
Unlike other models in PowerDesigner, the Requirements Model displays
views instead of diagrams.
There are two kinds of views in a requirements model:
♦
Requirements document views
♦
Traceability matrix views
Why views instead of diagrams?
A requirements model represents a detailed and structured list of actions that
must be implemented during a development process. A diagram, showing a
structure of interconnected symbols, is not the best way to represent a
numbered list of requirements. Document and matrix views are grids that
enumerate a list of requirements with respectively a set of attributes or
traceability links.
A requirements model can have as many views as necessary. You can
differentiate views by selecting requirements, customizing columns, changing
the traceability matrix type.
26
PowerDesigner
Chapter 2 Building a requirements model
Requirements views properties
You can display a requirements view property sheet using one of the
following methods:
♦
From the menu bar, select View→Requirements View→Properties
♦
From the Browser tree view, right-click the requirements view name or
icon, and select Properties in the contextual menu
The General page of a requirements view property sheet displays the
following properties:
Property
Description
Name
Name of the requirements view
Code
Code of the requirements view
Comment
Any comment on the requirements view
Traceability
matrix type
Only for traceability matrix views. Use the dropdown listbox
to select the type of linked objects (Design Object, File or
Requirement) displayed in the traceability matrix view
Parent
Name of the model or package to which the requirements
view belongs
Default view
If checked, the current requirements view (document or
matrix view) appears by default when opening the model
Requirements Model User's Guide
27
Defining requirements views
Defining requirements document views
Requirements document views are grids in which you create hierarchies of
requirements in rich edit text:
♦
Rows, corresponding to requirements, can be resized and moved
♦
Columns, corresponding to requirements attributes, are editable
Caution
You cannot insert graphics in a requirements document view.
Example of a requirements document view with a two level hierarchy:
Note: The arrow beside the first title ID indicates that the first requirement is
selected.
A requirements model can have as many requirements document views as
necessary. You can differentiate the views by customizing columns and
filtering rows.
For more information, see section Customizing columns and filtering
rows.
28
PowerDesigner
Chapter 2 Building a requirements model
Creating a requirements hierarchy
To create a requirements hierarchy in a requirements document view, use the
specific tools of the requirements document view toolbar:
Tool
Tooltip
Description
Insert a Row
Creates a new requirement at the same level
as a selected requirement
Insert Sub-Object
Creates a requirement inferior by one level
to a selected requirement
Promote
Upgrades a selected requirement by one
level
Demote
Downgrades a selected requirement by one
level
Show Titles and Texts
Shows the title and description of the
requirements.
This feature is also available in the
Requirements menu
Show Titles Only
Shows only the title of the requirements.
This feature is also available in the
Requirements menu
Show Current Title and
Text
When pushed-in, shows the title and
description of a selected requirement. When
released, shows only the title of the selected
requirement.
This feature is also available in the
Requirements menu
Requirements Model User's Guide
29
Defining requirements views
Redefining title fonts
You can modify the title fonts of a requirements document view through
model options.
To redefine title fonts in a requirements document view:
1
In the menu bar, select Tools→Model Options.
The Model Options dialog box appears.
2
In the left pane, select the Title Fonts category.
3
Select a title level in the Title level pane and define its characteristics in
the other panes.
4
Repeat step 3 for each title level you want to modify.
5
Click OK.
The title fonts are modified as defined in the Model Options dialog box.
30
PowerDesigner
Chapter 2 Building a requirements model
Customizing columns and filtering rows
You can customize columns and filter rows in a requirements document view.
To customize columns and filter rows in a requirements document
view:
1
In the requirements document view toolbar, click the Customize
Columns and Filter tool.
The Customize Columns and Filter dialog box appears.
2
< Selecting columns > Select or clear check boxes in the Displayed (D)
column, for columns you want to appear or not in the requirements
document view.
3
< Ordering columns > Use the arrowed buttons at the bottom-left corner
of the list to rearrange columns in the requirements document view.
4
< Filtering rows > Define an expression beside a column heading to
filter rows. For example, type “1.*” beside “Title ID Text”. Only the first
chapter requirements will appear in the requirements document view.
For more information on filtering rows, click the Help button or
see section Defining a filter on a list, in chapter Using the
PowerDesigner Interface, in the General Features Guide.
5
Click OK.
The requirements document view appears with customized columns and
filtered rows.
Requirements Model User's Guide
31
Defining requirements views
Defining traceability matrix views
You can link objects to a requirement to confirm that the requirement has
been integrated during the analysis and design processes. (See the
Traceability Links page of a requirement property sheet)
Traceability matrix views are grids which display the links between
requirements (in rows) and their linked objects (in columns).
There are three types of matrix views corresponding to three types of l
PowerDesigner®
Requirements Model
User's Guide
Version 11.0
DC00121-01-1100-01
Last modified: November 2004
Copyright © 1991-2004 Sybase, Inc. All rights reserved.
Information in this manual may change without notice and does not represent a commitment on the part of Sybase, Inc. and its
subsidiaries.
Sybase, Inc. provides the software described in this manual under a Sybase License Agreement. The software may be used only in
accordance with the terms of the agreement.
No part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual,
optical, or otherwise, without the prior written permission of Sybase, Inc.
Use, duplication, or disclosure by the government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of DFARS 52.2277013 for the DOD and as set forth in FAR 52.227-19(a)-(d) for civilian agencies.
Sybase, SYBASE (logo), ADA Workbench, Adaptable Windowing Environment, Adaptive Component Architecture, Adaptive Server,
Adaptive Server Anywhere, Adaptive Server Enterprise, Adaptive Server Enterprise Monitor, Adaptive Server Enterprise Replication,
Adaptive Server Everywhere, Afaria, AppModeler, APT Workbench, APTBuild, APT-Edit, APT-Execute, APT-Translator, APTLibrary, ASEP, AvantGo, AvantGo Application Alerts, AvantGo Mobile Document Viewer, AvantGo Mobile Delivery, AvantGo
Mobile Inspection, AvantGo Mobile Marketing Channel, AvantGo Mobile Pharma, AvantGo Mobile Sales, AvantGo Pylon, AvantGo
Pylon Application Server, AvantGo Pylon Conduit, AvantGo Pylon PIM Server, AvantGo Pylon Pro, Backup Server, BayCam, BitWise, BizTracker, Certified PowerBuilder Developer, Certified SYBASE Professional, Certified SYBASE Professional Logo,
ClearConnect, Client-Library, Client Services, CodeBank, Column Design, ComponentPack, Connection Manager, Convoy/DM,
Copernicus, CSP, Data Pipeline, Data Workbench, DataArchitect, Database Analyzer, DataExpress, DataServer, DataWindow, DBLibrary, dbQueue, Developers Workbench, Direct Connect Anywhere, DirectConnect, Distribution Director, Dynamic Mobility Model,
e-ADK, E-Anywhere, e-Biz Integrator, E-Whatever, EC Gateway, ECMAP, ECRTP, eFulfillment Accelerator, Electronic Case
Management, Embedded SQL, EMS, Enterprise Application Studio, Enterprise Client/Server, Enterprise Connect, Enterprise Data
Studio, Enterprise Manager, Enterprise Portal (logo), Enterprise SQL Server Manager, Enterprise Work Architecture, Enterprise Work
Designer, Enterprise Work Modeler, eProcurement Accelerator, eremote, Everything Works Better When Everything Works Together,
EWA, Financial Fusion, Financial Fusion (and design), Financial Fusion Server, Formula One, Fusion Powered e-Finance, Fusion
Powered Financial Destinations, Fusion Powered STP, Gateway Manager, GeoPoint, GlobalFIX, iAnywhere, iAnywhere Solutions,
ImpactNow, Industry Warehouse Studio, InfoMaker, Information Anywhere, Information Everywhere, InformationConnect, InstaHelp,
Intelligent Self-Care, InternetBuilder, iremote, iScript, Jaguar CTS, jConnect for JDBC, KnowledgeBase, Logical Memory Manager,
M-Business Channel, MBusiness Network, M-Business Server, Mail Anywhere Studio, MainframeConnect, Maintenance Express,
Manage Anywhere Studio, MAP, MDI Access Server, MDI Database Gateway, media.splash, Message Anywhere Server, MetaWorks,
MethodSet, ML Query, MobiCATS, My AvantGo, My AvantGo Media Channel, My AvantGo Mobile Marketing, MySupport, NetGateway, Net-Library, New Era of Networks, Next Generation Learning, Next Generation Learning Studio, O DEVICE, OASiS,
OASiS logo, ObjectConnect, ObjectCycle, OmniConnect, OmniSQL Access Module, OmniSQL Toolkit, Open Biz, Open Business
Interchange, Open Client, Open ClientConnect, Open Client/Server, Open Client/Server Interfaces, Open Gateway, Open Server, Open
ServerConnect, Open Solutions, Optima++, Orchestration Studio, Partnerships that Work, PB-Gen, PC APT Execute, PC DB-Net, PC
Net Library, PhysicalArchitect, Pocket PowerBuilder, PocketBuilder, Power++, Power Through Knowledge, power.stop, PowerAMC,
PowerBuilder, PowerBuilder Foundation Class Library, PowerDesigner, PowerDimensions, PowerDynamo, Powering the New
Economy, PowerScript, PowerSite, PowerSocket, Powersoft, PowerStage, PowerStudio, PowerTips, Powersoft Portfolio, Powersoft
Professional, PowerWare Desktop, PowerWare Enterprise, ProcessAnalyst, QAnywhere, Rapport, Relational Beans, RemoteWare,
RepConnector, Report Workbench, Report-Execute, Replication Agent, Replication Driver, Replication Server, Replication Server
Manager, Replication Toolkit, Resource Manager, RW-DisplayLib, RW-Library, SAFE, SAFE/PRO, SDF, Secure SQL Server, Secure
SQL Toolset, Security Guardian, SKILS, smart.partners, smart.parts, smart.script, SQL Advantage, SQL Anywhere, SQL Anywhere
Studio, SQL Code Checker, SQL Debug, SQL Edit, SQL Edit/TPU, SQL Everywhere, SQL Modeler, SQL Remote, SQL Server, SQL
Server Manager, SQL SMART, SQL Toolset, SQL Server/CFT, SQL Server/DBM, SQL Server SNMP SubAgent, SQL Station, SQLJ,
Stage III Engineering, Startup.Com, STEP, SupportNow, S.W.I.F.T. Message Format Libraries, Sybase Central, Sybase Client/Server
Interfaces, Sybase Development Framework, Sybase Financial Server, Sybase Gateways, Sybase IQ, Sybase Learning Connection,
Sybase MPP, Sybase SQL Desktop, Sybase SQL Lifecycle, Sybase SQL Workgroup, Sybase Synergy Program, Sybase Virtual Server
Architecture, Sybase User Workbench, SybaseWare, Syber Financial, SyberAssist, SybFlex, SybMD, SyBooks, System 10, System 11,
System XI (logo), SystemTools, Tabular Data Stream, The Enterprise Client/Server Company, The Extensible Software Platform, The
Future Is Wide Open, The Learning Connection, The Model For Client/Server Solutions, The Online Information Center, The Power of
One, TotalFix, TradeForce, Transact-SQL, Translation Toolkit, Turning Imagination Into Reality, UltraLite, UltraLite.NET, UNIBOM,
Unilib, Uninull, Unisep, Unistring, URK Runtime Kit for UniCode, Viewer, VisualWriter, VQL, WarehouseArchitect, Warehouse
Control Center, Warehouse Studio, Warehouse WORKS, Watcom, Watcom SQL, Watcom SQL Server, Web Deployment Kit,
Web.PB, Web.SQL, WebSights, WebViewer, WorkGroup SQL Server, XA-Library, XA-Server, XcelleNet, and XP Server are
trademarks of Sybase, Inc. or its subsidiaries.
All other trademarks are property of their respective owners.
Contents
About This Book
...........................................................................................vii
1
Requirements model basics..............................................1
Functional overview .................................................................. 2
What is a requirements model?................................................ 4
Objects in a requirements model ....................................... 5
Defining the requirements model environment ......................... 6
Selecting extended model definitions at model creation .... 6
Defining model options....................................................... 8
Requirements model extended dependencies................. 10
Defining a requirements model............................................... 11
Defining model properties ................................................ 11
Creating a requirements model........................................ 14
Opening an existing requirements model......................... 18
Detaching a requirements model from the workspace..... 18
Saving and closing a requirements model ....................... 19
Defining packages in a requirements model .......................... 20
Requirements package properties ................................... 21
Creating a requirements package .................................... 24
2
Building a requirements model.......................................25
Defining requirements views................................................... 26
Why views instead of diagrams?...................................... 26
Requirements views properties ........................................ 27
Defining requirements document views ........................... 28
Defining traceability matrix views ..................................... 32
Creating a requirements view........................................... 40
Defining requirements............................................................. 45
Defining requirements properties ..................................... 45
Creating a requirement..................................................... 55
Defining users and groups ...................................................... 57
Creating a user or a group ............................................... 57
User general properties.................................................... 58
Group general properties ................................................. 58
Attaching users and groups to a group ............................ 59
Defining glossary terms .......................................................... 60
Requirements Model User's Guide
iii
Glossary term general properties ..................................... 60
Creating a glossary term .................................................. 61
Using design objects............................................................... 62
Defining business rules........................................................... 63
What is a business rule? .................................................. 63
Activating business rules in a requirements model .......... 63
Defining business rules properties ................................... 66
Creating a business rule................................................... 67
Applying a business rule to a requirement ....................... 69
3
Working with a requirements model .............................. 71
Checking a requirements model............................................. 72
Defining options in Check Model...................................... 72
Selecting objects in Check Model .................................... 73
Checking a requirements model ...................................... 73
Displaying previously applied check options in a
requirements model ......................................................... 76
Making corrections based on requirements model check
results............................................................................... 76
Requirements model objects verified by Check Model........... 79
Business rule check ......................................................... 79
Glossary term check ........................................................ 80
User check ....................................................................... 80
Group check ..................................................................... 81
Requirement check .......................................................... 82
File check ......................................................................... 83
Extended object check ..................................................... 84
Extended link check ......................................................... 84
Replication check ............................................................. 84
Comparing and merging requirements models ...................... 85
Linking requirements with design objects ............................... 86
Attaching design objects to requirements ........................ 86
Attaching requirements to design objects ........................ 89
Exporting requirements as design objects.............................. 95
Importing design objects as requirements.............................. 99
4
Using MS Word with a requirements model ................ 103
Creating a requirements model from an MS Word
document .............................................................................. 106
Importing an MS Word document as a requirements
model.............................................................................. 106
Using MS Word to create a requirements model ........... 109
How are a model and a document linked?..................... 112
Creating a requirement from a selected text ........................ 117
iv
PowerDesigner
Creating an MS Word document from a requirements
model .................................................................................... 121
Inserting a requirements model into an existing MS Word
document .............................................................................. 124
Updating an MS Word document from a requirements
model .................................................................................... 127
Updating a requirements model from an MS Word
document .............................................................................. 129
Detaching an MS Word document from a requirements
model .................................................................................... 133
Detaching a requirements model from an MS Word
document .............................................................................. 135
Requirements Model Glossary ........................................................................137
Index
.........................................................................................139
Requirements Model User's Guide
v
vi
PowerDesigner
About This Book
Subject
Audience
This book describes the PowerDesigner Requirements Model environment. It
shows you how to do the following:
♦
Create requirements document views
♦
Create traceability matrix views
♦
Define specific objects in a requirements model
♦
Check a requirements model
♦
Compare and merge requirements models
♦
Link requirements with design objects (objects from other types of
models)
♦
Export requirements as design objects
♦
Import design objects as requirements
♦
Create and update an MS Word document from a requirements model
♦
Insert a requirements model into an existing MS Word document
♦
Create and update a requirements model from an MS Word document
This book is for anyone who wants to build a requirements model with
PowerDesigner. It does not require any particular knowledge. For more
information, see the Bibliography section at the end of this chapter.
Requirements Model User's Guide
vii
About This Book
Documentation
primer
The PowerDesigner modeling environment supports several types of models:
♦
Conceptual Data Model (CDM) to model the overall logical structure
of a data application, independent from any software or data storage
structure considerations
♦
Physical Data Model (PDM) to model the overall physical structure of
a database, taking into account DBMS software or data storage structure
considerations
♦
Object Oriented Model (OOM) to model a software system using an
object-oriented approach for Java or other object languages
♦
Business Process Model (BPM) to model the means by which one or
more processes are accomplished in operating business practices
♦
XML Model (XSM) to model the structure of an XML file using a DTD
or an XML schema
♦
Requirements Model (RQM) to list and document the customer needs
that must be satisfied during a development process
♦
Information Liquidity Model (ILM) to model the replication of
information from a source database to one or several remote databases
using replication engines
♦
Free Model (FEM) to create any kind of chart diagram, in a contextfree environment
This book only explains how to use the Requirements Model. For
information on other models or aspects of PowerDesigner, consult the
following books:
General Features Guide
To get familiar with the PowerDesigner
interface before learning how to use any of the models.
Conceptual Data Model Getting Started To learn the basics of the
CDM.
Conceptual Data Model User’s Guide
To work with the CDM.
Physical Data Model Getting Started
Physical Data Model User’s Guide
To learn the basics of the PDM.
To work with the PDM.
Object Oriented Model Getting Started
OOM.
Object Oriented Model User's Guide
viii
To learn the basics of the
To work with the OOM.
PowerDesigner
About This Book
Business Process Model Getting Started
To learn the basics of the
BPM.
Business Process Model User’s Guide
XML Model User’s Guide
To work with the BPM.
To work with the XSM.
Information Liquidity Model User’s Guide
Reports User’s Guide
To work with the ILM.
To create reports for any or all models.
Repository Getting Started
Repository User’s Guide
To learn the basics of the Repository.
To work in a multi-user environment using a
central repository.
Typographic
conventions
PowerDesigner documentation uses specific typefaces to help you readily
identify specific items:
♦
monospace text (normal and bold)
Used for: Code samples, commands, compiled functions and files,
references to variables.
Example: declare user_defined…, the
BeforeInsertTrigger template.
♦
UPPER CASE
Object codes, reversed objects, file names + extension.
Example: The AUTHOR table appears in the Browser. Open the file
OOMAFTER.OOM.
♦
bold text
Any new term.
Example: A shortcut has a target object.
♦
SMALL CAPS
Any key name.
Example: Press the ENTER key.
Bibliography
INCOSE (International Council on Systems Engineering) –
http://www.incose.org/practice/techactivities/semanagement/rwg.aspx
Special thanks to Dr Gregory Abowd and his team, Jeffrey Corn (Manager),
Travis Works (Architect), John Garrard (Programmer), Kesniel Acton
(Technical Writer), and Dinesh Krishna (Quality Assurance), who designed
the CyberFridge project – Copyright 2004, Georgia Tech Research
Corporation, Atlanta, Georgia 30332-0415, All Rights Reserved
Requirements Model User's Guide
ix
About This Book
x
PowerDesigner
C H A P T E R
1
Requirements model basics
About this chapter
Contents
This chapter presents the PowerDesigner Requirements Model. It provides
you with an introduction to the basic notions of the Requirements Model.
Topic
Page
Functional overview
2
What is a requirements model?
4
Defining the requirements model environment
6
Defining a requirements model
11
Defining packages in a requirements model
20
Requirements Model User's Guide
1
Functional overview
Functional overview
The Requirements Model (RQM) is a documentary model. It describes a
project by listing and explaining precisely what actions must be implemented
during a development process.
You can use the Requirements Model for any kind of structured technical
document (e.g. functional or technical specification, test plan) that must be
taken into account during a development process.
The Requirements Model displays no diagram but two different kinds of
views:
♦
Requirements document views: numbered lists of requirements with a
common set of properties
♦
Traceability matrix views: grids indicating the links between current
requirements and design objects (objects from other types of models),
external files or other requirements
For more information on requirements views, see section Defining
requirements views, in chapter Building a requirements model.
The Requirements Model allows you to:
♦
Build a requirements model from a structured technical document
♦
Check an existing or imported model
♦
Create links between requirements and design objects (objects from
other types of models)
♦
Create requirements from design objects, and vice versa
Some design objects (e.g. business rules, packages, use cases) may
correspond to requirements, and vice versa
♦
Create and update an MS Word document from a requirements model
To provide users with an MS Word document corresponding to the
requirements model
♦
Create and update a requirements model from an MS Word document
To start from an existing MS Word document
2
PowerDesigner
Chapter 1
Requirements model basics
From a requirements model, you can create design objects from
requirements, or create and update an MS Word document.
You can also create requirements from design objects, or create and update a
requirements model from an MS Word document.
Requirements Model User's Guide
3
What is a requirements model?
What is a requirements model?
A requirements model is a documentary model that helps you list and define
precisely what actions must be implemented during a development process.
Requirements are listed in document views, and their links with design
objects (objects from other types of models), external files or other
requirements are managed in traceability matrix views.
A requirements model sets and reminds what is at stake and what must be
done during a development process.
A requirements model is the reference model which defines the tasks and
orientates the work of all users and groups involved in a development
process.
Example of a requirements model (Browser and requirements document
view):
Demo models
Demo requirements models are available in the Examples directory.
4
PowerDesigner
Chapter 1
Requirements model basics
Objects in a requirements model
A requirements model has some specific objects:
Object
Description
Requirement
The name and description of an action. It can be
part of a hierarchy with parent and child
requirements. It must be defined precisely before
being assigned to users and groups
Glossary term
A word used in a requirements model. It must be
defined precisely to avoid misunderstandings and
set a common vocabulary
User
A person that is concerned by at least one
requirement
Group
A group of users that have a common interest in
satisfying at least one requirement
None of these objects has a graphic symbol, since there are no diagrams in a
requirements model. Requirements are listed in document views. Traceability
matrix views display the links between requirements and design objects
(objects from other types of models), external files or other requirements.
All objects appear in the Browser tree view.
Requirements Model User's Guide
5
Defining the requirements model environment
Defining the requirements model environment
The requirements model environment includes a set of parameters and
configuration options that define various aspects of the model content and
behavior. You can set these parameters:
♦
At model creation
♦
After creating a model with default options and parameters
♦
When creating a model template
Selecting extended model definitions at model creation
Extended model definitions (.XEM files) provide means for customizing and
extending PowerDesigner metaclasses, parameters and generation. Extended
model definitions are typed like models in PowerDesigner. You create an
extended model definition for a specific type of model and you cannot share
these files between heterogeneous models.
In the case of requirements models, you can use extended model definitions
as methodological supports for requirements management:
♦
Custom checks verify that methodological statements are satisfied. For
example, each requirement of scenario type must be associated with a
use case in an OOM
♦
You can customize the list of values for some properties. See Detail
properties, in Defining requirements properties, in chapter Building a
requirements model
♦
You can initialize the default values of a requirement, just after its
creation, by using the Initialize event handler
When you create a new requirements model, you can select one or several
extended model definitions and attach them to the model from the New
dialog box.
6
PowerDesigner
Chapter 1
Requirements model basics
You can choose one of the following options:
Option
Description
Share
Current extended model definition constantly refers to the extended
model definition stored in the Resource Files\Extended Model
Definitions directory. Any changes made to the extended model
definition are shared by all linked XEM
Copy
Current extended model definition is a unique copy of the extended
model definition stored in the Resource Files\Extended Model
Definitions directory. The current extended model definition is
independent of the original one, so modifications made to the
extended model definition in the Resource Files\Extended Model
Definitions directory are not available to the copied XEM. This one
is saved with the requirements model and cannot be used without it
For more information on extended model definitions, see chapter
Extended Model Definitions Reference Guide, in the Advanced User
Documentation.
Requirements Model User's Guide
7
Defining the requirements model environment
Defining model options
You can define the following options for a requirements model:
♦
Name/Code case sensitivity
♦
Title fonts
♦
Naming conventions
To define requirements model options:
1
In the menu bar, select Tools→Model Options.
The Model Options dialog box appears.
8
2
Select a category in the left pane and define its properties in the right
part of the dialog box.
3
Click OK.
PowerDesigner
Chapter 1
Requirements model basics
Name/Code case sensitivity
You can define the case sensitivity of names and codes for all objects in the
current model. When this check box is selected, it implies that you can have
two objects with identical name or code but different case in the same
namespace. You can modify the name and code case sensitivity during the
design process. However, if you do so, make sure you run the check model
feature to verify if the model does not contain any duplicate object.
Title fonts
You can define title fonts for requirements document views.
To define title fonts in Model Options:
1
Select a title level in the Title level pane.
2
Define the characteristics of the title level in the other panes.
3
Repeat steps 1 and 2 for each title level you want to modify.
4
Click OK.
The title fonts appear in the current document view as defined in the
Model Options dialog box.
Requirements Model User's Guide
9
Defining the requirements model environment
Naming conventions
You can also set naming conventions for each type of objects in your model.
For information on naming conventions, see section Defining naming
conventions, from chapter Managing Models, in the General Features Guide.
Requirements model extended dependencies
Extended dependencies are links between objects of a requirements model.
These links help to make object relationships clearer but are not interpreted
and checked by PowerDesigner, as they are meant to be used for
documentation purposes only.
You can complement these links by applying stereotypes. Stereotypes can be
used to define extended dependencies between objects in a requirements
model.
You can type stereotypes directly in the Stereotype column of the object
property sheet or select a value from the dropdown listbox, if you have
previously defined stereotypes in an embedded or imported extended model
definition (.XEM).
For more information on extended model definitions, see chapter
Extended Model Definitions Reference Guide in the Advanced User
Documentation.
10
PowerDesigner
Chapter 1
Requirements model basics
Defining a requirements model
This section presents the main operations you have to perform before starting
to build or work on a requirements model.
Defining model properties
The model property sheet displays the definition of the current model.
This section only explains the specific pages of a requirements model
property sheet.
For more information on the generic pages of a model property sheet,
see section Using property sheets in chapter Using the PowerDesigner
Interface, in the General Features Guide.
To define the properties of a requirements model:
1
Select Model→Model Properties.
or
Right-click the model name or icon in the Browser, and select Properties
in the contextual menu.
The model property sheet appears.
2
Define model properties in the different pages.
Requirements Model User's Guide
11
Defining a requirements model
3
Click OK.
Model General page
The General page of a requirements model property sheet displays the
following properties:
Property
Description
Name
Name of the model
Code
Code of the model
Comment
Descriptive label of the model
File name
Location of the model file. This box is empty if the model has
never been saved
Author
Author of the model. You can insert a name, a space or
nothing. If you insert a space, the Author field in the title box
remains empty. If you intentionally leave the box empty, the
Author field in the title box displays the user name from the
Version Info page of the model property sheet
Version
Version of the model. You can use this box to display the
repository version or a user-defined version of the model.
This parameter is defined in the display preferences of the
Title node
Default view
View displayed by default when opening the model
Model Detail page
The Detail page of a requirements model property sheet displays the
following properties:
Property
Description
Workload 1
Sum of all the workloads assigned to a first person or team
Workload 2
Sum of all the workloads assigned to a second person or team
Workload 3
Sum of all the workloads assigned to a third person or team
Workload 4
Sum of all the workloads assigned to a fourth person or team
A workload is the time assigned to a person or a team to satisfy a
requirement. This time is divided by as many persons in the team. You
should respect a unit for all workloads (hour or day). Values must be greater
or equal to zero, and limited to one decimal (For example: 3.5).
12
PowerDesigner
Chapter 1
Requirements model basics
A parent requirement workload is the sum of its child requirements
workloads. Parent workloads are automatically calculated once you enter
their child workloads. Model workloads are the sum of all child workloads.
Model and parent workloads are in read-only mode (grayed). You can only
modify child workloads.
Traceability Links page
To help understanding a requirements model or package, you can create links
with design objects (objects from other types of models) and external files
(MS Word, MS Excel, PowerDesigner...).
Use the following tools to create links with the current model or package:
Tool
Tooltip
Description
Add Links to Design Objects
Creates shortcuts to attach design
objects to the current model or
package. Design objects are selected
from design models open in the
workspace
Add Link to External File
Creates a link between an external file
(whatever the format) and the current
model or package. The external file is
stored in a Files folder within the
model
The standard Traceability Links page displays the following properties:
Property
Description
Linked Object
Design objects or external files linked to the requirements
model or package
Bookmark
Bookmark for the MS Word file linked with the requirements
model or package. Click a cell, then the Ellipsis button (…)
to create or modify a bookmark.
See Defining a bookmark for an MS Word file, in Defining
requirements properties, in chapter Building a requirements
model
You can modify the properties displayed in the Traceability Links page by
clicking the Customize Columns and Filter tool.
Requirements Model User's Guide
13
Defining a requirements model
Creating a requirements model
There are several ways to create a requirements model:
♦
Create a new requirements model
♦
Create a new requirements model using a template
♦
Create a new requirements model importing an MS Word document. See
Importing an MS Word document as a requirements model, in chapter
Using MS Word with a requirements model
Creating a requirements model using the New model option
When you create a requirements model using the New model option, an
Extended Model Definitions page appears.
The following options concern extended model definitions that you would
have selected:
14
Option
Description
Share
To use the shared extended model definitions stored in the Extended
Model Definitions directory of your installation. Any changes made
to the extended model definitions are available to the linked
requirements model
Copy
To create a copy of the extended model definition in the model. The
current extended model definition is independent from the original
extended model definition, so any changes made in the extended
model definition are not available to other models. The extended
model definition is saved with the model and cannot be used by
other models
PowerDesigner
Chapter 1
Requirements model basics
To create a new requirements model using the New model option:
1
In the menu bar, select File→New.
The New dialog box appears.
2
Select Requirements Model in the list of model types.
3
Select the New model radio button in the upper right part of the dialog
box.
4
If you want to attach one or more extended model definitions
to the model, select the extended model definitions of your choice in the
Extended Model Definitions page.
For more information on attaching extended model definitions to a
model, see section Selecting extended model definitions at model
creation.
5
Select either Share or Copy the extended model definitions.
Requirements Model User's Guide
15
Defining a requirements model
6
Click OK.
A new requirements model is created in the Workspace (Browser and
document view).
7
Select Model→Model Properties.
The model property sheet appears.
16
8
Type a name and a code for the model.
9
Click OK.
PowerDesigner
Chapter 1
Requirements model basics
Creating a requirements model using the New model from template option
To create a new requirements model using the New model from
template option:
1
Select File→New to display the New dialog box.
2
Select Requirements Model in the list of model types.
3
Select the New model from template radio button, in the upper right
part of the dialog box, to display the Template page.
4
Select a model template from the list.
List of templates
You can select user-defined model templates (use the Change userdefined model templates folder tool to specify the user templates
folder) and copy some existing models as model templates using the
Copy model to user-defined model templates folder tool.
For more information on model templates, see section Creating a
model, in chapter Managing Models, in the General Features Guide.
5
Click OK.
A new requirements model is created in the Workspace.
6
Select Model→Model Properties.
The model property sheet appears.
Requirements Model User's Guide
17
Defining a requirements model
7
Type a name and a code for the model.
8
Click OK.
Opening an existing requirements model
A requirements model has the file extension .RQM.
To open an existing requirements model:
1
Select File→Open.
or
Click the Open tool.
A standard Windows Open file dialog box appears.
2
Select a file with a .RQM extension.
3
Click Open.
The existing model appears in the workspace.
Detaching a requirements model from the workspace
When you detach a requirements model from a workspace, its node is
removed from the Browser, and it is no longer defined in the workspace. Yet
the file is not deleted from your operating environment.
To detach a requirements model from a workspace:
1
Right-click the requirements model node in the Browser and select
Detach from Workspace in the contextual menu.
A confirmation box asks if you want to save the requirements model.
2
Click Yes, if you want to save modifications to the requirements model.
Select or browse to a directory.
Type a name for the file and click the Save button.
or
Click No, if you do not want to save modifications to the file.
The requirements model is removed from the workspace.
18
PowerDesigner
Chapter 1
Requirements model basics
Saving and closing a requirements model
Saving a
requirements
model
To save a requirements model, choose one of the following options:
♦
Select File→Save
♦
Click the Save tool in the standard toolbar
♦
Right-click the requirements model in the Browser, and select Save in
the contextual menu
If it is the first time you save a requirements model, a standard Windows
Save As dialog box appears: Type a file name, choose a folder in your
directory and click Save.
Closing a
requirements
model
To close a requirements model, choose one of the following options:
♦
Select File→Close
♦
Right-click the requirements model in the Browser, and select Close in
the contextual menu
When a requirements model is closed, a red mark appears on its icon in the
Browser:
Requirements Model User's Guide
19
Defining packages in a requirements model
Defining packages in a requirements model
A package is a piece of a model.
When working with a large model, you can split the model into smaller
subdivisions to avoid manipulating the entire set of model objects. Packages
can be useful to assign portions of a model, representing different tasks and
subject areas, to different development teams.
In the following example, a package contains functional requirements and
another package contains non-functional requirements.
Package hierarchy
You can create several packages at the same hierarchical level within a
model, or decompose a package into other packages, and continue this
process without limitation in decomposition depth. Each package appears
with a default requirements view (document or matrix view). At each level of
decomposition, you can create several requirements views.
To display a package view, you must double-click its name or icon in the
Browser tree view.
For more information on packages, see the section Defining a package
in the General Features Guide.
Package
requirements
20
In a requirements model, packages only appear in the Browser tree view. To
add requirements to a package, you can:
♦
Create requirements directly from the package document view(s)
♦
In the Browser, select requirements from the model Requirements folder,
and drag and drop them either in the package document view(s) or
beneath the package Requirements folder (for root requirements), or
beneath other requirements (for child requirements)
PowerDesigner
Chapter 1
Requirements model basics
You can link requirements from different packages of the same model. Use
the Add Links to Other Requirements tool, in the Traceability Links page
of the requirements property sheet.
Requirements package properties
This section explains the specific pages of a requirements package property
sheet.
For more information on the generic pages of a property sheet, see
section Using property sheets in chapter Using the PowerDesigner Interface,
in the General Features Guide.
To display a package property sheet:
♦
Double-click its name or icon in the Browser
♦
Right-click its name or icon in the Browser, and select Properties in the
contextual menu
Package General page
The General page of a package property sheet displays the following
properties:
Property
Description
Name
Name that clearly identifies the package
Code
Codes are references for packages
Comment
Optional label that describes a package and provides additional
information
Stereotype
Sub-classification used to extend the semantics of an object without
changing its structure. It can be predefined or user-defined
Use parent
namespace
Defines the package as being the area in which the name of an
object must be unique in order to be used. The package is the
default namespace
Default view
View displayed by default when you open the package
Requirements Model User's Guide
21
Defining packages in a requirements model
Package Detail page
The Detail page of a package property sheet displays the following
properties:
Property
Description
Workload 1
Sum of all the workloads assigned to a first person or team to
satisfy all the requirements of the current package
Workload 2
Sum of all the workloads assigned to a second person or team
to satisfy all the requirements of the current package
Workload 3
Sum of all the workloads assigned to a third person or team to
satisfy all the requirements of the current package
Workload 4
Sum of all the workloads assigned to a fourth person or team to
satisfy all the requirements of the current package
A workload is the time assigned to a person or a team to satisfy a
requirement. This time is divided by as many persons in the team. You
should respect a unit for all workloads (hour or day). Values must be greater
or equal to zero, and limited to one decimal (For example: 3.5).
A parent requirement workload is the sum of its child requirements
workloads. Parent workloads are automatically calculated once you enter
their child workloads. Package workloads are the sum of all their child
workloads. Package, sub-package and parent workloads are in read-only
mode (grayed). You can only modify child workloads.
22
PowerDesigner
Chapter 1
Requirements model basics
Traceability links page
To help understanding a requirements package or model, you can create links
with design objects (objects from other types of models) and external files
(MS Word, MS Excel, PowerDesigner...).
Use the following tools to create links with the current package or model:
Tool
Tooltip
Description
Add Links to Design Objects
Creates shortcuts to attach design
objects to the requirements package or
model. Design objects are selected
from design models open in the
workspace
Add Link to External File
Creates a link between an external file
(whatever the format) and the
requirements package or model. The
external file is stored in a Files folder
within the model
The standard Traceability Links page displays the following properties:
Property
Description
Linked Object
Design objects or external files linked to the requirements
package or model
Bookmark
Bookmark for the MS Word file linked with the requirements
package or model. Click a cell, then the Ellipsis button (…)
to create or modify a bookmark.
See Defining a bookmark for an MS Word file, in Defining
requirements properties, in chapter Building a requirements
model
You can modify the properties displayed in the Traceability Links page by
clicking the Customize Columns and Filter tool.
Requirements Model User's Guide
23
Defining packages in a requirements model
Creating a requirements package
You can create a requirements package using the following methods:
♦
Right-click the model item in the Browser, and select New→Package in
the contextual menu. A root package (directly linked to the model item)
is created
♦
Right-click a package item in the Browser, and select New→Package in
the contextual menu. A sub-package is created under the selected
package
♦
Use the List of Packages in the Model menu
To create a requirements package using the List of Packages:
1
In the menu bar, select Model→Packages.
The List of Packages appears.
If the model document view is open in the workspace, the List of
Packages displays the root packages of the model.
If a package document view is open in the workspace, the List of
Packages displays the sub-packages of the current package.
2
Click a blank line in the list.
A package appears in the list, with generic name and code.
3
Type a name and a code for the package.
4
Click OK.
The new package appears in the Browser tree view as a root package or
a sub-package.
To display a package view, double-click its name or icon in the Browser.
24
PowerDesigner
C H A P T E R
2
Building a requirements model
About this chapter
Contents
This chapter describes how to build a requirements model (RQM). It explains
the role of each object in a requirements model and how to create them.
Topic
Page
Defining requirements views
26
Defining requirements
45
Defining users and groups
57
Defining glossary terms
60
Using design objects
62
Defining business rules
63
Requirements Model User's Guide
25
Defining requirements views
Defining requirements views
Unlike other models in PowerDesigner, the Requirements Model displays
views instead of diagrams.
There are two kinds of views in a requirements model:
♦
Requirements document views
♦
Traceability matrix views
Why views instead of diagrams?
A requirements model represents a detailed and structured list of actions that
must be implemented during a development process. A diagram, showing a
structure of interconnected symbols, is not the best way to represent a
numbered list of requirements. Document and matrix views are grids that
enumerate a list of requirements with respectively a set of attributes or
traceability links.
A requirements model can have as many views as necessary. You can
differentiate views by selecting requirements, customizing columns, changing
the traceability matrix type.
26
PowerDesigner
Chapter 2 Building a requirements model
Requirements views properties
You can display a requirements view property sheet using one of the
following methods:
♦
From the menu bar, select View→Requirements View→Properties
♦
From the Browser tree view, right-click the requirements view name or
icon, and select Properties in the contextual menu
The General page of a requirements view property sheet displays the
following properties:
Property
Description
Name
Name of the requirements view
Code
Code of the requirements view
Comment
Any comment on the requirements view
Traceability
matrix type
Only for traceability matrix views. Use the dropdown listbox
to select the type of linked objects (Design Object, File or
Requirement) displayed in the traceability matrix view
Parent
Name of the model or package to which the requirements
view belongs
Default view
If checked, the current requirements view (document or
matrix view) appears by default when opening the model
Requirements Model User's Guide
27
Defining requirements views
Defining requirements document views
Requirements document views are grids in which you create hierarchies of
requirements in rich edit text:
♦
Rows, corresponding to requirements, can be resized and moved
♦
Columns, corresponding to requirements attributes, are editable
Caution
You cannot insert graphics in a requirements document view.
Example of a requirements document view with a two level hierarchy:
Note: The arrow beside the first title ID indicates that the first requirement is
selected.
A requirements model can have as many requirements document views as
necessary. You can differentiate the views by customizing columns and
filtering rows.
For more information, see section Customizing columns and filtering
rows.
28
PowerDesigner
Chapter 2 Building a requirements model
Creating a requirements hierarchy
To create a requirements hierarchy in a requirements document view, use the
specific tools of the requirements document view toolbar:
Tool
Tooltip
Description
Insert a Row
Creates a new requirement at the same level
as a selected requirement
Insert Sub-Object
Creates a requirement inferior by one level
to a selected requirement
Promote
Upgrades a selected requirement by one
level
Demote
Downgrades a selected requirement by one
level
Show Titles and Texts
Shows the title and description of the
requirements.
This feature is also available in the
Requirements menu
Show Titles Only
Shows only the title of the requirements.
This feature is also available in the
Requirements menu
Show Current Title and
Text
When pushed-in, shows the title and
description of a selected requirement. When
released, shows only the title of the selected
requirement.
This feature is also available in the
Requirements menu
Requirements Model User's Guide
29
Defining requirements views
Redefining title fonts
You can modify the title fonts of a requirements document view through
model options.
To redefine title fonts in a requirements document view:
1
In the menu bar, select Tools→Model Options.
The Model Options dialog box appears.
2
In the left pane, select the Title Fonts category.
3
Select a title level in the Title level pane and define its characteristics in
the other panes.
4
Repeat step 3 for each title level you want to modify.
5
Click OK.
The title fonts are modified as defined in the Model Options dialog box.
30
PowerDesigner
Chapter 2 Building a requirements model
Customizing columns and filtering rows
You can customize columns and filter rows in a requirements document view.
To customize columns and filter rows in a requirements document
view:
1
In the requirements document view toolbar, click the Customize
Columns and Filter tool.
The Customize Columns and Filter dialog box appears.
2
< Selecting columns > Select or clear check boxes in the Displayed (D)
column, for columns you want to appear or not in the requirements
document view.
3
< Ordering columns > Use the arrowed buttons at the bottom-left corner
of the list to rearrange columns in the requirements document view.
4
< Filtering rows > Define an expression beside a column heading to
filter rows. For example, type “1.*” beside “Title ID Text”. Only the first
chapter requirements will appear in the requirements document view.
For more information on filtering rows, click the Help button or
see section Defining a filter on a list, in chapter Using the
PowerDesigner Interface, in the General Features Guide.
5
Click OK.
The requirements document view appears with customized columns and
filtered rows.
Requirements Model User's Guide
31
Defining requirements views
Defining traceability matrix views
You can link objects to a requirement to confirm that the requirement has
been integrated during the analysis and design processes. (See the
Traceability Links page of a requirement property sheet)
Traceability matrix views are grids which display the links between
requirements (in rows) and their linked objects (in columns).
There are three types of matrix views corresponding to three types of l