IRqA® 2.1 INCOSE survey © TCP S.I. June,
2002
IrqA 2.1 Survey Response
1 Capturing
Requirements/identification........................................ 5
2 Capturing system element
structure.............................................. 7
3 Requirements flowdown.......................................................................... 7
3.2 Allocation
of performance requirements to system elements (weight, risk, cost, etc.)... 8
4.4 Requirement
performance verification from system elements (roll up of actuals)....... 10
5 Configuration Management................................................................. 10
5.1 History
of requirement changes, who, what, when, where, why, how........................ 10
6 Documents and other
output media................................................ 11
6.4 Custom
output features and markings (user definable tables, figures, security
markings..) 11
8 Interfaces to other
tools.................................................................... 13
11 Standards--which one’s
do you comply with?......................... 17
12 Support and maintenance................................................................... 17
12.5 Internet
access/World Wide Web home page location.......................................... 17
Using existing document information (such as
glossary, index, etc.) aids the user in requirement analysis, identification of
requirements, etc.
FULL
IRqA can
automatically create unique IDs for Requirements and Services following the
numbering pattern specified by customer ( Prefix, Suffix, number of digits, etc
). Besides that, the user can afterwards re-code a group of requirements, or
manually assign specific codes ( IRqA will allow to enter unused codes only ),
and IRqA will keep the internal coherence of all the traceability links of the
requirements.
The
requirement ID is not reused when the requirement is deleted.
IRqA
Requirements analysis support may be summarised as follows:
1.
IRqA
Automatic Text Analyser helps the user to discover “hidden” relationships
between requirements and other analysis elements, based on keywords used in
their names and/or description.
2.
IRqA
also provides a Problem Domain Model ( Glossary ) for users to define terms
specific to their environment that can be used to promote correct usage of
those terms throughout the project. Concept synonyms handling is also
supported.
3.
Multi-dimensional
Organisational models, additional to the classical hierarchical structure
provide added elements/requirements structure.
1.1.1
Input
document change/comparison
analysis
The ability to compare/contrast two different
versions of a source document
FULL
Users can
track requirements Change History through versioning, since different
requirements versions can be stored in IRqA. Afterwards, they can be easily
compared by selecting any two different versions from the requirement version
list.
Apart from
version control, IRqA supports project baseline comparison through a Project
Comparer, where any element differences ( requirements, UML elements,
relationships, … ) are shown for any two project baselines.
Generated
documents comparison is also supported via MS Word’s compare utility.
A mechanism for automatic identification of
requirements by key words, structure, unique identifiers, etc. to create
requirements from the text.
FULL
Parsing can
be used in IRqA in three ways:
1) First,
parsing can be used for automatic identification of requirements from a
Microsoft Word text file. By simply selecting MS-Word type styles, requirements
are parsed and imported from documents into the requirements repository.
2) Second,
IRqA Text Analyzer is mainly used for discovering ( and assigning ) relations
between reqs and different specification items ( concepts, services, attributes
) by parsing reqs description.
3) Finally,
csv files can be used to import requirements.
The ability to identify requirements from a
text file via interactive means such as mouse highlighting of the requirement
text or prompting by the system “is this a requirement?”.
PARTIAL
Users can
select text styles that will correspond to req. code, req. name and req. description
in a text capture dialog. After that, automatic parser will recognize
requirements without manual intervention.
A manual means of identifying or creating
requirements.
FULL
Requirements
may be manually created directly into IRqA without capturing them from a text
file.
A mechanism for inputing/identifying
requirements from outside of the tool.
FULL
IRqA
provides three methods:
1) IRqA’s Microsoft Word import utility
( see 1.2).
2) Via csv ( text delimited ) files.
3) By using IRqA-Face ( a COM API ),
requirements can be entered into IRqA repositories from external applications.
1.5.1
Batch-mode
document/source-link update
Does the tool have the ability to update
existing linked documents from new/changed versions of the source documents
without having to re-establish traceability links ?
FULL
IRqA supports
links for each requirement with external files through references. When a file
is linked, users can update the content as needed, and IRqA will retain the
link from requirements. If the name of the file changes, link must be changed
accordingly.
Any file type
( text, spreadsheets, tables, video, drawings, etc) can be created by using an
external tool and then linked to a requirement within IRqA.
Apart from
those “external” documents containing additional information about
requirements, users can generate customized documents on demand with IRqA
Report Manager.
Does the tool have the ability to classify/categorize
requirements during identification?
FULL
The tool
allows creating new attributes to be assigned to the requirements.
Requirements
grouping, classification, and categorization are fully supported via two
methods:
1) Creating
classical hierarchical "hard" structure ( assigning parent req. or
creating a child from another )
2) Using
our "soft" classifying method based on previously named attributes.
It will allow users to have as many attributes ( and so, reqs. classifications
) and attribute values as they need. They can be shown either as a tree, or in
a graphical mode through active block diagrams.
Once the requirements have been captured, the
allocation of requirements to sub-system elements takes place. The tool must capture these elements so
links/allocations can be made to those sub-systems elements.
Can the tool graphically capture system
implementation (such as architecture, functional decomposition, WBS, etc.) and
display them graphically such that requirements can be linked to them ?
FULL
In addition
to the generic structural elements, the tool provides the following graphical
features:
1) Block
diagrams: they can be used to represent Blocks and the relationships between
them, to navigate across the specification and to show traceability between
elements contained in related blocks. In this sense, block diagrams may serve
as Traceability Diagrams, WBS or functional decomposition, among others.
2) Domain
diagrams: they are used to represent Domains and their relationships (basically
used as Architecture diagrams).
On the
other hand, IRqA Traceability Matrix displays all element relationships in a
filterable grid. Within the traceability matrix, users select the pair of
element type, from requirements to analysis elements, which they want to show
as rows and columns: requirements, diagrams, services, test scenarios,
concepts, etc.
Can the tool textually capture system implementation
(such as architecture, functional decomposition, WBS, etc.) and display them
textually such that requirements can be linked to them?
FULL
The tool
provides several elements to textually capture system structure:
1) Domain facets: Classification elements
that depend on the problem description.
2) Blocks: Grouping elements that
permit to cluster requirements and other specification elements. They are
qualified containers.
3) Domains: Grouping elements that
permit to represent sub-systems or other architecture-dependant elements. They
are basically containers.
Any of the
above elements can be linked to requirements either in the Traceability Matrix
or in a specific tab in Requirements view.
Once the requirements have been captured and
system architecture captured, requirements are allocated to the various system
elements.
The ability to derive/create additional
requirements and links between them such as requirement to requirement, or
requirement to text (representing trade studies) to derived requirements.
FULL
IRqA
provides several mechanisms to derive requirements:
1) Traditional hierarchy
2) Services: Explicit specification
elements separated from requirements, which may be linked to them with the
semantics "service solves requirements". They are traditionally known
as "System/Software Requirements", and may be described as Use Cases
within IRqA.
3) Block diagrams: Blocks may represent
different levels of requirements detail, and the relations between them the
derivation/partitioning from one level to another (traceability matrixes are
associated and can be accessed to these relationships).
4) Relationships between requirements:
The user can establish direct relationships between a group of manually
selected requirements and enter information on the reason why this relationship
is established.
The ability to link performance requirements to
system elements such as weight, cost, throughput, etc. This also includes the
ability to allocate portions of that performance requirement to system
elements.
FULL
Quantitative
values may be associated to requirements (non-functional in the case mentioned)
or services through user-defined dynamic attributes.
The linking of requirements to system elements
can be accomplished from either end of the link--from the implementation back
to the requirement or from the requirement down to the system element.
FULL
In IRqA,
links are set from either the receiving or the starting end of a link. You can select a requirement and then link it
to those system elements which implements it, and vice versa.
Apart from
this direct linking from requirements to system elements, IRqA allows to
accomplish it through coherent intermediate steps. Block diagrams permit not
only to show a traceability chain in both directions ( req->system element,
system element->req ), but also to edit and show derived traceability
relationships between non-subsequent blocks. This is called indirect/transitive
traceability and represents, for example, the implementation elements that are
impacted by each user requirement and vice versa. Intermediate elements depend
on the derivation structure established. Basic derivation in IRqA takes into
account Services (and other lower level specification items, like activities
and sub-activities).
Also critical is the ability to attach
rationale, assignments, criticality, test/validation and many other issues to
the requirement, allocation, and the system element to which a requirement is
linked.
FULL
Basic
requirement's structure may be enriched by the addition of customized
attributes such as criticality, importance, cost, etc. IRqA provides two
different user-definable mechanisms to do that: Management Facets (enumerated
management characteristics such as criticality, priority or req. state ) and Dynamic Attributes (text, boolean,
numeric, user-definable type attributes such as cost, etc).
Tests are
explicitly treated by the tool through specific modelling elements called
"Test Scenarios" that may be allocated to requirements or services to
represent acceptance tests. Traceability Matrixes include req.-system element
or req.-test scenarios relationships, among others.
Apart from
that, as mentioned in 1.5.1, any file type ( text, tables, spreadsheets,
drawings, etc ) can be linked to a requirement.
Once the allocations are complete, the user
will want the ability to see the links where they come from, where they go, and
why they apply.
The tool should allow the user to identify
inconsistencies such as unlinked requirements or system elements (orphans).
FULL
The list of
requirements can be ordered by the services related to them. This simple feature
allows the user to immediately identify requirements which are not taken into
account in the services specification, or services which are not linked to any
requirement.
The
Traceability Matrix allows users to examine the relationship between requirements
and their related system elements ( concepts, test scenarios, services,
diagrams, etc ). For example, one can discover requirements not related to any
test scenario by simply showing the Requirement-Test Scenarios Traceability
Matrix. So, that information can be used as an analysis tool for identification
and correction of ambiguity, contradiction, duplication and/or omission.
Apart from
these features, the tool provides the following automatic consistency checks
and reports, among others, in an optional module ( IRqA-Quality&Metrics ):
With the requirement links in place, the user
needs the ability to follow the links to see where they come from and where
they go to.
PARTIAL
At the
element level, specific tabs in all views show listed basic information about
all elements linked for each requirement/service/test scenario/etc. So, you
don’t need to navigate among different views to have full visibility of
existing links.
On the
other hand, Block diagrams in combination with direct and indirect traceability
matrixes and associated reports provide this feature at the architectural
level.
Throughout the life of the project, the
requirement management tool will be used to verify that the requirements have
been met. The tool should provide the
ability to document that the requirement was fulfilled, how it was done, and
who was responsible.
FULL
Complete
traceability throughout lifecycle ( from requirements to acceptance test ) is
supported within IRqA: no need to go to any other tool to verify where the requirements
have been met or which requirements are fulfilled by which system element.
Impact
analyses and change assessments supported.
Once performance requirements have been allocated
to system elements, the requirements management tool should support the
verification of those requirements by rolling up actuals and reporting on
variances (this is the allocated weight versus the actual weight).
PARTIAL
Requirement
attributes and facets can be used to record "planned" vs.
"actual" values. Both values
can be included in reports so the variance can be implicitly shown.
Once requirements have been captured, the
requirement management tool should maintain a history of requirement changes,
who changed it, when it was done, why it was done, etc. Some of this tracking could be automatic,
others could be procedural such as a rationale for the change and how the
change is to be accomplished.
FULL
Complete
individual requirements ( and also services ) evolution through version control
may be maintained in the repository.
The history
of each element may be tracked through the versions ( configuration audit logs
) and the rationale of each change may be saved.
Requirement
date, time, user, change reason, among others, are recorded in addition to
requirement name and description changes in req. history.
Users can
compare two different versions over the history of an element obtaining the
differences between them.
At various times the requirements will need to
be baselined (saved and locked away).
The requirements management tool should support this along with the
ability to compare and contrast between various baselines.
FULL
Configuration
management is supported at two different levels of the tool:
1) Project level (baselining and
backup). IRqA supports multiple baselines for each project that can be modified
only by users with the appropriate security level. A powerful Project Comparer
Wizard allows the users to compare between any two baselines.
2) Partition level: A coherent part of
the project may be locked in order to be shared with a separate analysis team,
or to partially baseline the project.
The requirements should be able to be protected
from modification, viewing, etc. by individuals or groups.
FULL
As an
administrative feature, the tool provides complete access controls, based on an
Access Partitions ( project organisation ) and User Profiles combination,
configurable for each project. The specification administrator can define the
different access rights (read, read/write) that each group has over each
partition.
The tool also
provides a check-in/check-out mechanism to avoid incoherent updates to the
repository.
The requirements management tool should output
documentation in various military/commercial standard formats.
FULL
Since you
can define your own report set and structure, you can obtain reports in the
standard format you may need: 490, 498, etc.
The tool should also support document quality
and consistency checking through spell checking, data dictionaries, acronym
tables, etc.
PARTIAL
Only
concept synonyms/data dictionaries handling is supported.
Next major release is going to include spell
checking.
Once the information is loaded, the
requirements management tool should support the generation of presentation
quality charts and graphs.
PARTIAL
Supported
diagrams ( use cases diagrams, block diagrams, etc.) and traceability matrixes
can be included in reports.
Charting
and graphing can be easily done connecting IRqA repository to MS Access or
Excel via ODBC.
The tool should support the output of documents
in finished form including page security markings, graphics/figures, user
definable tables, indexes, etc.
FULL
Users
create their own document templates, look & feel and report structure. IRqA
Report Manager can combine dynamic information obtained from IRqA with “static”
information previously added to the document in order to obtain finished
documents after generating them.
The tool should allow the user to view the
document on-screen in finished format.
FULL
Since our
documents are Word based, users can always view them before printing.
Tool users need to status information in the
requirements management tool.
FULL
By using
the appropriate Status attribute(s), users can track the status of each
element, at different levels, and include status information in IRqA reports.
6.6.1
Technical
Performance Measurement status accounting
Status current technical performance of various
allocated performance requirements and monitor progress towards goals.
FULL
Since architecture, functional decomposition or WBS can be managed via
Block Diagrams, users can add technical progress and technical
risk/difficulties attributes to each block. This information, along with cost
assessment information ( that you can also maintain within IRqA ), and schedule
performance will provide Project Managers a more accurate progress assessment
of their projects.
Besides
that, a customized Technical Performance Measurement status report can be
created through IRqA Report Manager based on above attributes.
6.6.2
Requirement
progress/status reporting
Status reporting on current
compliance/non-compliance to various requirements.
FULL
As in
6.6.1, Req.Name-Req.Status is one of the possible reports IRqA may produce
listing what has failed or pass up to report date.
6.6.3
Other
ad hoc queries and searches
The requirements management tool should support
ad hoc queries and searches per the user’s discretion.
FULL
By using
our powerful Filter Engine, you can obtain complex searches ( AND, OR, and NOT
operators are allowed ) filtering by any combination of: author, date,
relations, text, classification item, domain, parent requirement and
specification item, among others.
In any
case, if you need an ad-hoc query, you can always access ( in read-only mode )
the repository via SQL (ODBC mechanism), although up to now, IRqA users have
never needed this option.
Since Systems Engineers rarely work as
individuals, the ability for a team of engineers to look/work on the same
information at the same time is critical.
The tool should support a team of engineers
reviewing, marking up, and commenting on requirements or implementation
alternatives.
FULL
IRqA uses
the standard check-in/check-out technique, so when a requirement is being
modified, it cannot be modified by any other user until it is explicitly
released, although other user can read it while the requirement is locked ( if
he has the appropriate read permission ).
With IRqA,
users can set different partitions and the database will remain consistent
between all “views”. Furthermore, any change will be reflected dynamically
across the database.
For
managing implementation/specification alternatives:
1) You can
always create implementation/specification alternatives by using IRqA modelling
capabilities.
2) And
relate them to the specific item they come from ( requirement or change
proposal ).
For each
requirement a Comments tab exists, where every user with write permission can
enter a text commenting on some aspect of the requirement.
Access by the team to the database must be
tempered by multi-level access control (i.e. the ability to protect things from
being modified). This also includes the ability to submit changes into an
approval cycle (for acceptance/voting) before committing the changes to the
tool for everyone to see.
FULL
Fully
user-defined access control supported.
The IRqA
administrator can define different access levels, by:
1) Creating
a Users structure, via User Groups
2) Creating
Partitions, and including specification elements in them
3)
Assigning privileges to the User Groups to those partitions
Privileges
include: Read Only, Write Own and/or Write all.
You can
only make changes ( such as status in approval cycle ) to those elements you
have been granted permission to.
The
approval cycle can be customized for every project or organization through the
user-defined attributes.
Requirements management must have the ability
to communicate requirements to other domain-specific design tools (CASE, EE,
etc.).
8.1.1
Interfaces
to other tools?
What tools will your requirements management
tool interface with or talk to?
FULL
1) XMI (XML Metadata Interchange OMG
standard) Import/Export capabilities with UML design tools: R. Rose, Together,
and any XMI compliant tool.
2) IRqA-Rational Rose live-link.
3) DOORS, for capturing requirements
from DOORS repositories.
4) Microsoft Word, Excel
8.1.2
External
Applications Program Interface available
To support the wide variety of tools in use by
engineers, the requirements management tool should have programmable access to
the information contained in the tool’s database (to get access to and deposit
information).
FULL
We provide
an open COM API ( IRqA-Face), which is intended to be used for those purposes
via both compiled and scripting standard languages ( ASP, Visual
Basic, PHP, etc ).
8.1.3
Support
Open database system (standard query access)
Does the tool support Open Database standards
such as standard query languages or exchange formats?
FULL
1) Any
commercial RDBMS can be used as IRqA repository container ( Oracle, Informix,
SQL-Server, MS-Access ).
2) You can
use SQL for accessing IRqA repositories ( although only query access is
recommended ).
3) Standard
ODBC and DSNs mechanisms are used for connecting IRqA to repositories.
8.1.4
Import
of existing data from various standard file formats
Does the tool have the ability to import
existing data (such as an ASCII text file containing link information) to
create structures within the tool without having to re-enter the information?
FULL
Two
import/export standard formats are allowed:
1) CSV format, for the entire project
structure
2) XML format: XMI for UML elements.
We are
planning to provide full specification XML import/export cabability.
8.2.1
Exchange
of information between same-tool different installations
Since the tool will be used at different sites
and different projects, how does the tool exchange information between
different tool installations or databases?
FULL
There are
several possibilities, although the recommended is to use the Project
partitioning capabilities: this feature allows users to divide, lock and export
projects into sub-projects by means of IRqA block diagrams, that can be easily
and separately exchanged between different sites. Those sub-projects will be
managed by separate teams and, after working on them, they can be returned for
resynchronizing the database, keeping the consistency between parts.
8.2.2
Consistency/comparison
checking between same-tool datasets
Does the tool support comparing/contrasting of
different same-tool datasets to allow consistency and verification checking?
FULL
IRqA
Project Comparer allows users to diff IRqA projects/datasets.
Does the tool support a single user or multiple
concurrent users?
FULL
IRqA is
engineered as a fully multi-user environment, and supports as many concurrent
users as your commercial DB engine can manage.
Which platforms and operating systems does the
tool run on?
1) PC-Client: PC platform using
Microsoft Operating Systems: MS Windows 95, 98, NT 4.0, 2000, XP.
2) Web Client ( IRqA-Net ): Any Java
enabled web browser.
3) License Server (multi-user): PC/NT
4.0, 2000.
4) Repository : Any RDBMS server
with ODBC connectivity.
Does the tool use a proprietary or commercially
available database?
FULL
Commercial
database. The commercial RDBMs supported are: Oracle, Informix, MS SQLServer
and MS Access. Projects are scalable: they can initially be created in
MS-Access and, as they grow, they can be exported to Oracle or Informix
on-the-fly.
Please identify hardware/software configuration
requirements:
64
MB minimum.
Pentium
II or higher.
40
MB per client.
Does the user have the ability to run a report
and look at a requirement at the same time?
FULL
The tool
GUI is designed in independent windows. For example, two different projects may
be opened at the same time and different views of the same project may be
managed in parallel.
If the tool allows for multiple windows/views
into the tool--does a change in one view automatically reflect in all other
views?
PARTIAL
Most views
are automatically updated, although some of them have a “Refresh” button to
prevent users from being shown unnecessary updates.
Does the tool support graphical input and
manipulation of data?
FULL
1)
Specification description: Different graphical and semi-graphical modelling
techniques ( UML, E/R, scenarios, etc ) are fully supported by IRqA. Graphical
editors are included to create and maintain those graphs.
2)
Specification arquitecture: The requirements structure may be defined (and not
just represented) in a graphical way in IRqA using block and domain diagrams.
These diagrams are not just graphs: you can navigate over the specification
through them.
If your tool supports a window’s standard,
which one(s)?
IRqA is a
Microsoft Windows application following the look&feel of standard Microsoft
applications.
Does the tool allow the user to create and
playback commands or macros that allow the user to automate various tedious
tasks?
FULL
Although
IRqA automates tedious tasks, we provide an open COM API (IRqA-Face), which can
be used for those purposes by using standard scripting languages, such as ASP
or PHP, not having to learn a new scripting language.
Does the tool allow a user to access the tool
or database with a web browser?
FULL
IRqA-Net
allows users to access IRqA repositories with a standard web browser.
PARTIAL
IRqA
includes a wastebasket where deleted items are stored.
Users can
restore items from the wastebasket if they have permission to.
Which military/commercial standards does your
tool comply with--including database standards, output document standards,
exchange standards, display/graphics standards, etc.
·
Database:
Open ODBC connection to repository
·
Information
exchange: csv format, XML format
·
Graphics:
UML notation, E/R diagrams, DFDs.
·
Output
documents: Reports may be produced in a variety of industry standard formats or
user-defined formats.
Does your tool have a warranty, if so what is
it?
FULL
TCP S.I.
guarantees that the products shall substantially work in accordance with the
User's Manual of each product for a period of 90 days, provided that the same
are operated in accordance with the technical and operational specifications
that are featured in the User's Manuals.
Does the tool support network licensing
(floating, node locked, etc.), if so which license manager?
FULL
IRqA
support both floating and seat/node locked licensing.
For now, a
proprietary license manager is used, although we’re planning to migrate to a
commercial one.
How often are software updates released; are
updates separately priced items, etc.?
FULL
Major IRqA
versions are released annually, approximately, available at no cost under
Maintenance contract (25% of the list price of the licences at the time of
purchase).
Official
patch updates are also available at no cost under Maintenance contract.
Are the users manuals online, is there online
help with the tool?
FULL
Both online
help and printed manual are included with the tool.
The IRqA CD
includes the full set of Manuals in PDF format, as well as a sample tutorial
project to support the user in learning the IRqA features.
Does the tool supplier have an Internet e-mail
address or World Wide Web home page location?
If so, what is the Uniform Resource Locator (URL)?
FULL
E-mail: info@irqa.net
URL:
http://www.irqaonline.com/ ( under
construction )
What type of phone support is available from
the tool supplier?
FULL
IRqA’s Helpdesk available: 9:00am to 6:30 PM West
Europe local time at:
+34-91-748-98-31.
In
addition, questions can be emailed to support@irqa.net
or faxed to +34-91-748-98-76 at any time.
Basic phone
support includes:
·
Bugs
and associated fixes/patches information.
· Installation & configuration support.
· Training
FULL
The
following IRqA training courses are available:
Customized
training is also available.
FULL
IRqA
training courses can be made available at customer’s location.
What is the recommended training time for a
user to become proficient in using the tool?
The
training time ranges from one to five days to become proficient with the tool,
depending on the user profile and the level of interaction the student will
have with IRqA.
FULL
Users
attending the IRqA Basic Course may perform software installations.
1.
IRqA
supports the complete Requirements Engineering process:
a.
Requirements
Capture
b.
Requirements
Analysis
c.
Requirements
Organization & Classification
d.
Specification
building
e.
Acceptance
Test management
f.
Requirements
Management
2.
Both classical functional and O.O. approaches
are supported for requirements analysis and specification building.
3.
With
IRqA, you can implement your RE management
process.
4.
The
following modelling capabilities
for each Requirements Engineering activity are supported:
Requirements Organization
& Classification:
•Block
diagrams
•Domain diagrams
•Multidimensional classification
•Classical
“hard” hierarchy
Requirements Analysis
•Concept models
•Classification models
System Specification building
•State
Charts (UML)
•Scenarios ( Semi-graphical notation
)
Software Analysis
•O.O.
Models (UML)
•E/R
Models
Software Specification building
•State
Charts (UML)
•DFDs
•Actor/Use
Case diagrams ( UML)
•Scenarios
( Semi-graphical notation ), for specifying Use Cases
Acceptance Test
•Test
Scenarios, Fit Criteria
•Scenarios
( Semi-graphical notation ), for specifying Test Scenarios
5.
Migration Support (Version Update). IRqA
provides a project migration tool that allows exporting information from previous versions of the
tool to newer and from a RDBMS format to another (e.g., from MS Access to
Oracle).
6.
You
can archive project data outside the tool via:
·
RDBMS
standard archiving procedures
·
csv
files standard archiving procedures
7.
Advanced reporting features. IRqA provides the ability to
create reports with different level of detail depending on the recipient. For
example: Functional Specification for the customer, Test related Information
for QM, Detailed Technical Information for R and D.
IRqA
Report Wizard allows users to easily define and compose their own report
structure for each specific need, by using predefined report elements, and at
the proper level of detail. Once reports structure is properly created, and by
using Word templates, you may generate reports on the fly. For example, users
might create reports containing different views on the data: a view organized
by Software-Solution or Module for the developer, Component or Process
Structure for the customer.
Simple,
Grouped, Compounds, Hierarchical and Tabular reports are supported.
8.
IRqA
provides the possibility to flag requirements, which might be potentially added features for a new version of the
standard release, including a work flow for review, acceptance,.. of these
flagged requirements, via two flagging procedures:
1) User-defined, dynamic attributes
2) Using our "facet" features, a
powerful classification tool, that allows you to:
·
Define
several workflows: one for reqs. and another for added features.
·
Define
several versions (n) where to dynamically assign those features.
9.
With
IRqA, you can organize your requirements in blocks ( categories ), assigning (
possibly different ) user groups to each of them for e-mail
notification purposes. Each time a requirement included in such
blocks changes, all users having interest in been notified are sent an e-mail.
10. IRqA provides a simple cost estimation module based in the concept
of "Use Case-Point" (similar to Function-Point).
11. Complexity metrics. IRqA provides absolute and ratio
parameters (i.e. average of requirements per concept or average of requirements
per Use Case) to assure specification quality completeness, consistency and
verifiability. It also supports specification stability metrics, to determine
the variability of individual and grouped elements.
Sales Contact
Baldo
Rincon
Phone: +34 91 748 98 78
Fax: +34 91 748 98 76
E-mail: mailto:brincon@tcpsi.es
Technical Support
Phone:
+34 91 748 9831.
E-mail: mailto:support@irqa.net