IRqA® 2.1

INCOSE survey

 

© TCP S.I.

June, 2002

 

 
IrqA 2.1 Survey Response

 


1     Capturing Requirements/identification........................................ 5

1.1      Input document enrichment/analysis......................................................................... 5

1.1.1       Input document change/comparison analysis............................................................................. 5

1.2      Automatic parsing of requirements........................................................................... 5

1.3      Interactive/semi-automatic requirement identification................................................. 6

1.4      Manual requirement identification............................................................................. 6

1.5      Batch mode operation............................................................................................. 6

1.5.1       Batch-mode document/source-link update................................................................................... 6

1.6      Requirement classification....................................................................................... 6

2     Capturing system element structure.............................................. 7

2.1      Graphically capture systems structure...................................................................... 7

2.2      Textural capture of systems structure....................................................................... 7

3     Requirements flowdown.......................................................................... 7

3.1      Requirements derivation (req. to req, req. to analysis/text)......................................... 8

3.2      Allocation of performance requirements to system elements (weight, risk, cost, etc.)... 8

3.3      Bi-directional requirement linking to system elements................................................ 8

3.4      Capture of allocation rationale, accountability, test/validation, criticality, issues, etc.--if so how and what mechanism does it use?...................................................................................................................... 8

4     Traceability analysis.................................................................................. 9

4.1      Identify inconsistencies (orphans, if so what kind of...).............................................. 9

4.2      Visibility into existing links from source to implementation--i.e. follow the links............ 9

4.3      Verification of requirement (was it done, how was done)......................................... 10

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

5.2      Baseline/Version control........................................................................................ 10

5.3      Access control (modification, viewing, etc.)............................................................ 11

6     Documents and other output media................................................ 11

6.1      Standard specification output (if so what kind)......................................................... 11

6.2      Quality and consistency checking (spell, data dictionary,)......................................... 11

6.3      Presentation output................................................................................................ 11

6.4      Custom output features and markings (user definable tables, figures, security markings..)          11

6.5      WYSIWYG previewing of finished output.............................................................. 12

6.6      Status reporting..................................................................................................... 12

6.6.1       Technical Performance Measurement status accounting........................................................ 12

6.6.2       Requirement progress/status reporting...................................................................................... 12

6.6.3       Other ad hoc query’s and searches.............................................................................................. 12

7     Groupware........................................................................................................ 13

7.1      Support of concurrent review, markup, and comment............................................... 13

7.2      Multi-level assignment/access control..................................................................... 13

8     Interfaces to other tools.................................................................... 13

8.1      Inter-tool communications...................................................................................... 13

8.1.1       Interfaces to other tools?............................................................................................................... 13

8.1.2       External Applications Program Interface available................................................................ 14

8.1.3       Support Open database system (standard query access)........................................................ 14

8.1.4       Import of existing data from various standard file formats?................................................... 14

8.2      Intra-tool communication....................................................................................... 14

8.2.1       Exchange of information between same-tool different installations..................................... 14

8.2.2       Consistency/comparison checking between same-tool datasets........................................... 15

9     System Environment................................................................................... 15

9.1      Single user/multiple concurrent users...................................................................... 15

9.2      Multiple Platforms/Operating Systems?.................................................................. 15

9.3      Commercial vs. unique database............................................................................ 15

9.4      Resource requirements.......................................................................................... 15

9.4.1       Memory requirements..................................................................................................................... 15

9.4.2       CPU requirements........................................................................................................................... 15

9.4.3       Disk space requirements................................................................................................................ 15

10      User Interfaces......................................................................................... 15

10.1       Doing one thing while you are looking at another.................................................. 15

10.2       Simultaneous update of open views..................................................................... 16

10.3       Interactive graphical input/control of data............................................................ 16

10.4       Which window’s standard do you follow?............................................................ 16

10.5       Executable via scripts (recordable) or macros...................................................... 16

10.6       Web browser interface...................................................................................... 16

10.7       Undo Function................................................................................................... 16

11      Standards--which one’s do you comply with?......................... 17

12      Support and maintenance................................................................... 17

12.1       Warrantee......................................................................................................... 17

12.2       Network license policy....................................................................................... 17

12.3       Maintenance and upgrade policy......................................................................... 17

12.4       Online help........................................................................................................ 17

12.5       Internet access/World Wide Web home page location.......................................... 17

12.6       Phone support................................................................................................... 18

13      Training........................................................................................................... 18

13.1       Tool specific training classes.............................................................................. 18

13.2       Training available at customer's location.............................................................. 18

13.3       Recommended training time............................................................................... 18

13.4       Software installation with only basic training........................................................ 18

14      What other requirements management features do you as a tool supplier think are important (modeling, etc.)?................................................... 18

14.1       Other important IRqA features........................................................................... 19

14.2       Contact Information........................................................................................... 20


 

 

1        Capturing Requirements/identification

1.1          Input document enrichment/analysis

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.

 

1.2          Automatic parsing of requirements

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.

 

1.3          Interactive/semi-automatic requirement identification

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.

 

1.4          Manual requirement identification

A manual means of identifying or creating requirements.

FULL

 

Requirements may be manually created directly into IRqA without capturing them from a text file.

 

1.5          Batch mode operation

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.

 

1.6          Requirement classification

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.

2        Capturing system element structure

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.

 

2.1          Graphically capture systems structure

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.

 

2.2          Textual capture of systems structure

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.

3        Requirements flowdown

Once the requirements have been captured and system architecture captured, requirements are allocated to the various system elements.

 

3.1          Requirements derivation (req. to req, req. to analysis/text)

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.

 

3.2          Allocation of performance requirements to system elements (weight, risk, cost, etc.)

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.

 

3.3          Bi-directional requirement linking to system elements

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).

 

3.4          Capture of allocation rationale, accountability, test/validation, criticality, issues, etc.--if so how and what mechanism does it use?

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.

4        Traceability analysis

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.

 

4.1          Identify inconsistencies (orphans, if so what kind of...)

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 ):

 

 

4.2          Visibility into existing links from source to implementation--i.e. follow the links

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.

 

4.3          Verification of requirement (was it done, how was done)

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.

 

4.4          Requirement performance verification from system elements (roll up of actuals)

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.

5        Configuration Management

5.1          History of requirement changes, who, what, when, where, why, how.

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.

 

5.2          Baseline/Version control

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.

 

5.3          Access control (modification, viewing, etc.)

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.

6        Documents and other output media

6.1          Standard specification output (if so what kind)

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.

 

6.2          Quality and consistency checking (spell, data dictionary,)

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.   

 

6.3          Presentation output

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.

 

6.4          Custom output features and markings (user definable tables, figures, security markings..)

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.

 

6.5          WYSIWYG previewing of finished output

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.

 

6.6          Status reporting

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.

7        Groupware

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.

 

7.1          Support of concurrent review, markup, and comment

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.

 

7.2          Multi-level assignment/access control

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.

8        Interfaces to other tools

8.1          Inter-tool communications

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          Intra-tool communication

 

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.

9        System Environment

9.1          Single user/multiple concurrent users

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.

 

9.2          Multiple Platforms/Operating Systems?

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.

 

9.3          Commercial vs. unique database

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.

 

9.4          Resource requirements

Please identify hardware/software configuration requirements:

 

9.4.1              Memory requirements

64 MB minimum.

 

9.4.2              CPU requirements

Pentium II or higher.

 

9.4.3              Disk space requirements

40 MB per client.

10User Interfaces

10.1     Doing one thing while you are looking at another

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.

 

10.2     Simultaneous update of open views

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.

 

10.3     Interactive graphical input/control of data

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.

 

10.4              Which window’s standard do you follow?

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.

 

10.5              Executable via scripts (recordable) or macros

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.

                                             

10.6     Web browser interface

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.

 

10.7     Undo Function

PARTIAL

IRqA includes a wastebasket where deleted items are stored.

Users can restore items from the wastebasket if they have permission to.

11Standards--which one’s do you comply with?

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.

12Support and maintenance

12.1              Warranty

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.

 

12.2              Network license policy

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.

 

12.3              Maintenance and upgrade policy

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.

 

12.4              Online help

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.

 

12.5     Internet access/World Wide Web home page location

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 )

http://www.irqa.net/

 

12.6              Phone support

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

 

12.7     Tool specific training classes

FULL

 

The following IRqA training courses are available:

 

 

Customized training is also available.

 

12.8     Training available at customer's location

FULL

 

IRqA training courses can be made available at customer’s location.

 

12.9     Recommended training time

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.

 

12.10                      Software installation with only basic training

FULL

 

Users attending the IRqA Basic Course may perform software installations.

13What other requirements management features do you as a tool supplier think are important (modelling, etc.)?

 

13.1     Other important IRqA features

 

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.

 

13.2     Contact Information

 

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