PowerDesigner
®
Requirements Model
User's Guide
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.227-7013 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, Edit, Execute, Translator, APT-Library, 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, Bit-Wise, 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, DB-Library, 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, Net-Gateway, 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.
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
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
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
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.
Subject
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 businesspractices
♦ 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
context-free 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 To learn the basics of the PDM.
Physical Data Model User’s Guide To work with the PDM.
Object Oriented Model Getting Started To learn the basics of the OOM.
Object Oriented Model User's Guide To work with the OOM.
Business Process Model Getting Started To learn the basics of the BPM.
Business Process Model User’s Guide To work with the BPM.
XML Model User’s Guide To work with the XSM.
Information Liquidity Model User’s Guide To work with the ILM.
Reports User’s Guide To create reports for any or all models.
Repository Getting Started To learn the basics of the Repository.
Repository User’s Guide To work in a multi-user environment using a central repository.
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.
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
Typographic conventions
Requirements model basics
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
About this chapter
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
From a requirements model, you can create design objects from requirements, or create and update an MS Word document.
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
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.
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
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
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.
2 Select a category in the left pane and define its properties in the right part of the dialog box.
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.
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).
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.
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 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
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:
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
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 <optional> 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.
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.
8 Type a name and a code for the model.
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 user-defined model templatesfolder 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.
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.
Saving and closing 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.
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:
Saving 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.
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.
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)
Package hierarchy
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
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).
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
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 <optional> 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.
Building a requirements model
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
About this chapter
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.
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
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.
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
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.
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.
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 links:
♦ Between requirements and design objects (objects from other types of
models).
These links confirm that the requirements have been integrated in the analysis and design processes
♦ Between requirements and external files (MS Word, MS Excel,
PowerDesigner…).
The links with MS Word are managed automatically. You can also link requirements with pieces of various documents (e.g. a planning)
♦ Between requirements from different hierarchies.
Example of a traceability matrix view with requirements links:
The Current cell properties group box displays the properties of a selected link:
Property Description
Link type Additional information about the object linked to the current requirement
Bookmark Only with MS Word files.
Bookmark for the MS Word file linked with the current requirement. (See Defining a bookmark in an MS Word document)
You can also create or delete traceability links with the tool in the upper left corner of the Current cell properties group box. (See Creating a traceability link and Deleting a traceability link)
Selecting the type of traceability links
You can select the type of traceability links displayed in a traceability matrix view.
To select the type of traceability links:
1 In the menu bar, select Requirements→Change Traceability Matrix
Type.
or
In the matrix view toolbar (on the upper left corner of the grid), click the
ChangeTraceability Matrix Type tool.
2 In the Traceability Matrix Type dialog box, select the type of objects linked with requirements.
3 Click OK.
Selecting rows and columns
You can select the objects displayed in the rows and columns of a traceability matrix view.
To select rows and columns:
1 In the menu bar, select Requirements→Select Rows/Columns. or
In the matrix view toolbar (on the upper left corner of the grid), click the
Select Rows/Columns tool.
The Select Row/Column Objects dialog box appears.
The Row Object Selection page displays a list of requirements. The Column Object Selection page displays a list of linked objects, depending on the type of traceability links you have selected. (See Selecting the type of traceability links)
2 In each list, click the Deselect All tool, and select the objects you want to appear in rows and columns of the traceability matrix view.
3 Click OK.
Adding columns
You can add columns to a traceability matrix view.
To add a column:
1 In the menu bar, select Requirements→Select Rows/Columns. or
In the matrix view toolbar (on the upper left corner of the grid), click the
Select Rows/Columns tool.
2 Click the Column Object Selection tab to display the list of objects selected for columns.
3 In the Column Object Selection page, click the Add New Column Object tool.
♦ The Select Design Objects dialog box appears for a matrix view
with design objects links.
You can select objects from any design model open in the workspace
♦ The standard Open dialog box appears for a matrix view with
external files links
Note: The Add New Column Object tool is not available for a matrix view with requirement objects links, because requirements from different models cannot be linked
4 Select the design object or external file you want to add in a new column of the matrix view.
5 Click OK in the Select Design Objects dialog box, or Open in the Open dialog box.
6 Click OK in the Select Row/Column Objects dialog box.
Filtering with empty rows and columns
You can filter a traceability matrix view by hiding or displaying its full or empty rows and columns:
♦ In the menu bar, select Requirements→Display Only Full
Rows/Columns or Display Only Empty Rows/Columns
♦ In the matrix view toolbar, use the following tools:
Tool Tooltip Description
Display Only Full Rows/Columns
When pushed-in, it displays only full rows and columns, so that you focus only on
requirements with links
Display Only Empty Rows/Columns
When pushed-in, it displays only empty rows and columns that need to be linked
Creating a traceability link
To create a traceability link in a traceability matrix view:
♦ Click an empty cell in the traceability matrix view, and type “V” or press
the space bar
♦ Use the Current cell properties group box
To create a traceability link using the Current cell properties group box:
1 In the traceability matrix view, click an empty cell where you want to create a link between a requirement and a design object, an external file, or another requirement.
2 Click the Create TraceabilityLink tool.
The traceability link is created. A check mark appears in the selected cell and the current cell properties are modified.
3 <optional> Select a value in the Link type dropdown listbox to specify the kind of linked object involved in the traceability link.
Note: The Link type values are customizable through an extended model definition. (See Customizing a list of values in section Detail properties, in Defining requirements properties)
The traceability link is automatically created in the Traceability Links page of the concerned requirement property sheet.
A bookmark can be defined when you create a link with an MS Word file, in the Traceability Links page of a requirement property sheet. (See Defining a bookmark in an MS Word document)
Deleting a traceability link
To delete a traceability link in a traceability matrix view:
♦ Click a full cell in the traceability matrix view, and press the Delete key
or the space bar
♦ Use the Current cell properties group box
To delete a traceability link using the Current cell properties group box:
1 In the traceability matrix view, click the cell corresponding to the traceability link you want to delete.
2 Click the Delete Traceability Link tool.
The traceability link is deleted. The check mark disappears from the selected cell and the current cell properties are grayed.
The traceability link is automatically deleted from the Traceability Links page of the concerned requirement property sheet.
Creating a requirements view
You can create a requirements view (document or traceability matrix view):
♦ Using the View menu
♦ Using the Requirements menu
♦ Using the requirements view toolbar
♦ Using the Browser tree view
Using the View menu
To create a requirements view using the View menu:
1 In the menu bar, select View→Requirements View→New
View→Requirements Document View or Traceability Matrix View.
The New View dialog box appears.
2 Type a name and a code for the new view.
3 Click OK.
You can now work on this new requirements view.
Using the Requirements menu
To create a requirements view using the Requirements menu:
♦ In the menu bar, select Requirements→Create a Requirements Document
View or Create a Traceability Matrix View.
A new requirements document view or traceability matrix view appears in the workspace.
Caution
As the new requirements view is identical to the original
requirements view, you might have the impression that nothing has changed in the GUI.
Using the requirements view toolbar
You can create a new view using the toolbar located on top of a requirements view.
In the requirements view toolbar, select one of the following tools:
Tool Tooltip Description
Create a Requirements Document View
A new requirements document view is created with the same hierarchy of requirements as the original view. You can modify the new view without altering the original view.
This feature is also available from the
Requirements menu
Create a Traceability Matrix View
A new traceability matrix view is created with the same traceability links as the original view. You can modify the new view without altering the original view.
This feature is also available from the
Requirements menu
Caution
As the new requirements view is identical to the original requirements view, you might have the impression that nothing has changed in the GUI. To make sure that a new requirements view has been created, check its name in the PowerDesigner general title bar or in the Browser tree view.
Using the Browser tree view
To create a requirements view using the Browser:
1 In the Browser, right-click a model or a package name or icon, to display its contextual menu.
2 In the contextual menu, select New→Requirements Document View or
A new requirements document view appears in the workspace, along with its property sheet.
or
A new traceability matrix view appears in the workspace, along with its property sheet.
3 Type a name and a code for the new requirements view.
4 < Only for traceability matrix views > Select the type of linked objects in the Traceability matrix type dropdown listbox.
5 Click OK.
Defining requirements
A requirement is a clear and precise description of an action that must be implemented during a development process.
Example of a requirement in a requirements document view:
Note: All columns (except Title ID) are editable.
Defining requirements properties
To display a requirement property sheet:
♦ Double-click the arrow beside the requirement in the requirements
document view
♦ Double-click its name or icon in the Browser tree view
General properties
The General page of a requirement property sheet displays the following properties:
Property Description
Parent Name of the parent requirement. For root requirements (directly linked to the Requirements folder), it is the requirements model name
Title ID Read-only number expressing the place of the requirement in the requirements hierarchy. For example: 1.3.2
Title Name of the requirement
Code Code of the requirement
Detail properties
The Detail page of a requirement property sheet displays the following properties:
Property Description
Comment Any comment on the requirement
Stereotype Sub-classification used to extend the semantics of an object without changing its structure. It can be predefined or user-defined
Type Type of requirement from the process point of view (See Customizing a list of values)
Status Validation level for a requirement (See Customizing a list of values)
Priority Priority level attached to a requirement. The value cannot be null or negative, and is limited to one decimal. For example: 1.5
Selected If checked, the requirement is retained for the project. If cleared, the requirement is excluded from the project and the sum of workloads
Risk Level of risk, would a requirement not be satisfied (See Customizing a list of values)
Verification Test level for a requirement (See Customizing a list of values)
Workload 1 Time assigned to a first person or team to satisfy the current requirement (See note below)
Workload 2 Time assigned to a second person or team to satisfy the current requirement (See note below)
Workload 3 Time assigned to a third person or team to satisfy the current requirement (See note below)
Workloads
You should respect a unit for all workloads (hour or day). A workload is divided by as many persons in a team. Values must be greater or equal to zero, limited to one decimal (e.g. 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. Parent workloads are in read-only mode (grayed). You can only modify child workloads.
Some requirement properties come with a predefined list of values. You can define your own list of values by creating an extended model definition (See following procedure). The new list will replace the predefined one. In the case of several extended model definitions, all the lists are merged.
You can customize the list of values for the following requirement properties:
♦ Type
♦ Status
♦ Risk
♦ Verification
You can also customize the list of values for the Link type property in traceability matrix views, and for the Type property in the User Allocations page of requirements property sheets. (See note in step 8)
To customize a list of values:
1 In the menu bar, select Model→Extended Model Definitions.
The List of Extended Model Definitions appears.
2 Click the Add a Row tool.
or
Click a blank line in the list.
An extended model definition appears with generic name and code.
3 Type a name and a code for the new extended model definition.
4 Click Apply.
5 Double-click the arrow at the beginning of the line.
The extended model definition property sheet appears.
6 In the left pane, expand the Settings category.
8 In the Custom Values category, expand the Requirement category.
Note: Expand the TraceabilityLink category to define Link type values in traceability matrix views, and the UserAllocation category to define Type values in the User Allocations page of requirements property sheets.
The right panel displays the name and comment (definition, default values) for the selected property.
10 In the Value table, click the Add a Row tool.
or
Click a blank line in the list.
11 Referring to the default values in the Comment box, type a value in the
Value column (this value will appear in the property dropdown listbox) and a code in the Name column (this code is stored in the system).
12 Repeat step 11 for each value you want to create.
13 Click OK in the extended model definition property sheet.
The new extended model definition appears in the List of Extended Model Definitions.
14 Click OK in the List of Extended Model Definitions.
Traceability links
To increase the scope of a requirement, you can create links with design objects (objects from other types of models), external files (MS Word, MS Excel, PowerDesigner…) and other requirements that bring additional information about the requirement.
The Traceability Links page of a requirement property sheet allows you to attach design objects, external files and other requirements to the current requirement:
Tool Tooltip Description
Add Links to Design Objects Creates shortcuts to attach design objects to the current requirement. 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 requirement. The external file is stored in a Files folder within the model.
See Defining a bookmark in an MS Word document
Add Links to Other Requirements Creates a link between the current requirement and other
Defining a bookmark in an MS Word document
In the Traceability Links page of a requirement property sheet, click the Add Link to External File tool, then select an MS Word file in your directory. A message appears indicating that the system is parsing the MS Word document to extract its paragraph titles.
When the parsing is over, the Select a bookmark dialog box appears.
Expand the Entry points node, to reveal the paragraph titles hierarchy, and select one title as bookmark.
Click OK.
To modify a bookmark in an MS Word document, click the bookmark cell in the Traceability Links page of the requirement property sheet, then click the Ellipsis button (…) to redefine a bookmark.
To display a bookmark in an MS Word document, select the linked file in the Traceability Links page of the requirement property sheet, then click the Properties tool in the page toolbar. The MS Word document appears starting with the title defined as bookmark.
User allocations
The User Allocations page of a requirement property sheet allows you to assign users and groups, defined in the model, to the accomplishment of the current requirement.
Click the Add Objects tool to select the users and groups you want to attach to the requirement:
For more information on users and groups, see section Defining users and groups.
Related glossary terms
The Related Glossary Terms page of a requirement property sheet allows you to attach specific terms, defined in the model, to the current requirement. It lists the vocabulary that is used for the current requirement, or that should be used for matters concerning the current requirement.
For more information on glossary terms, see section Defining glossary terms.
Modifying a bookmark
Creating a requirement
You can create a requirement:
♦ From the contextual menu of the model item in the Browser tree view
♦ From a requirements document view
To create a requirement from a requirements document view:
1 Click any empty cell in the requirements document view.
or
Click the Insert a Row tool in the requirements document view toolbar. A requirement appears in the requirements document view, with predefined properties.
Note: All columns (except Title ID) are editable.
2 Double-click the arrow beside the requirement Title ID.
or
Click the Properties tool in the requirements document view toolbar.
3 Type a title and a code for the requirement.
4 Define other properties in the different pages of the requirement property sheet.
Defining users and groups
Users are all the people concerned by at least one requirement defined in a requirements model.
Groups are categories of users specialized in one or more aspects of a development process (e.g. a QA team). A group is concerned by at least one requirement defined in a requirements model.
Users and groups are attached to requirements via the User Allocations page of the requirements property sheet.
The Dependencies page of a user or group property sheet displays:
♦ The list of requirements assigned to that user or group
♦ The groups or child groups linked to that user or group
Creating a user or a group
You can create a user or a group:
♦ From the List of Users or Groups in the Model menu
♦ From the Browser tree view
To create a user or a group from the Browser tree view:
1 In the Browser tree view, right-click the model name or icon.
2 In the model contextual menu, select New→User. or
Select New→Group.
The user or group property sheet appears.
3 Type a name and a code for the new user or group.
4 Click OK.
User general properties
The General page of a user property sheet displays the following properties:
Property Description
Name Name of the user
Code Code of the user
Comment Any comment on the user
Stereotype Sub-classification used to extend the semantics of an object without changing its structure. It can be predefined or user-defined
Email address E-mail address of the user
Group general properties
The General page of a group property sheet displays the following properties:
Property Description
Name Name of the group
Code Code of the group
Comment Any comment on the group
Stereotype Sub-classification used to extend the semantics of an object without changing its structure. It can be predefined or user-defined
Attaching users and groups to a group
The Group Users page of a group property sheet allows you to attach users and child groups to the current group.
To attach users and groups to a group:
1 In the Group Users page of a group property sheet, click the Add Objects tool.
The Add Objects dialog box appears.
2 In the User page, select the users you want to attach to the current group. 3 In the Group page, select the child groups you want to attach to the
current group.
4 Click OK.
The selected users and child groups appear in the Group Users page of the current group property sheet.
Groups hierarchy
Defining glossary terms
Glossary terms are clearly defined words used to avoid misinterpretations in a requirements model. Use the Description tab, in the Notes page of a glossary term property sheet, to give a full and precise description of a glossary term.
Glossary terms are attached to requirements via the Related Glossary Terms
page of the requirements property sheet.
The Dependencies page of a glossary term property sheet displays the requirements associated with the glossary term.
Glossary term general properties
The General page of a glossary term property sheet displays the following properties:
Property Description
Name Name of the glossary term
Code Code of the glossary term
Comment Any comment on the glossary term
Creating a glossary term
You can create a glossary term:
♦ From the Browser tree view
♦ From the List of Glossary Terms in the Model menu
To create a glossary term from the List of Glossary Terms:
1 In the menu bar, select Model→Glossary Terms.
The List of Glossary Terms appears.
2 Click the Add a Row tool.
or
Click a blank line in the list.
A new glossary term appears in the list, with generic name and code.
3 Click Apply.
4 Double-click the arrow at the beginning of the line.
The glossary term property sheet appears.
5 Type a name and a code for the new glossary term.
6 Click OK.
The new glossary term appears in the List of Glossary Terms.
Using design objects
Design objects are objects defined in design models (CDM, PDM, OOM, BPM, FEM, XSM, ILM). These objects can be an additional source of information about requirements, either in the making of a requirements model, or as a result of a requirement satisfaction.
You can perform several actions concerning design objects in a requirements model:
Action Description
Attach design objects to requirements In the Traceability Links page of a requirement property sheet, click the
Add Links to Design Objects tool to select design objects in a model open in the workspace, and attach them to the current requirement. Design objects are listed as external shortcuts in the List of Shortcuts.
At the other end of the links, the requirement appears in the
Requirements page of the design objects property sheet.
See section Linking requirements with design objects, in chapter Working with a requirements model
Export requirements as design objects In the menu bar, select
Requirements→Export Requirements
as Design Objects, to open the Requirement Export Wizard which allows you to create design objects from requirements.
See chapter Working with a requirements model
Import design objects as requirements In the menu bar, select
Requirements→Import Design
Objects as Requirements, to open the Requirement Import Wizard which allows you to create requirements from design objects.
