This page contains answers to common questions, along with tips
and tricks that we have found useful.
- Which methdology is WIBNI designed to
support?
- Why do you no longer charge for a licence?
- Can I share the WIBNI database with other
users?
- Can I modify the reports and/or forms?
- Why don't my requirements appear in the
reports ?
- Why are some fields missing from the report?
- Why do my reports have unnecessary blank
pages?
- How can I import requirements?
- How do I update from WIBNI 1.1 to 1.2?
- How can I delete unwanted requirements?
- How can I delete items from the history?
There is no particular methodology; we did not intend WIBNI
to be prescriptive and we hope WIBNI is flexible enough to be used in various
ways. The important thing is that you embed it within your own processes and
controls.
On one level, you can use WIBNI just for storing
requirements and tracking their status. You do not need to use the Business
Events and Use Cases at all.
Alternatively, you could use WIBNI for a more complex
requirements gathering process. For example, you could
- define the Business Events for a system
- define Use Cases for each Business Event
- for each Use Case, identify Requirements
WIBNI allows you to track the dependencies between all these
items and allows you to check for possible inconsistencies, e.g. requirements
that have no use cases. However, it does not force you to follow any
particular order of working.
Because we are not actively developing WIBNI any longer and
we cannot provide support any longer. WIBNI is basically a straightforward
database that would do exactly what it says on the box ... if it had one.
Yes - just place it on a networked drive. WIBNI is a shareable database, but bear in mind that
Microsoft Access cannot handle a large number of simultaneous users. The
default record locking is set to 'No Locks', so 'Edited
Records' — WIBNI locks the record you're editing, so no other user can
change it. It might also lock other records that are stored nearby on your
disk. This strategy ensures that you can always finish making changes that you
start. It is a good choice if you don't have editing conflicts often.
To change the locking strategy,
- On the Tools menu, click Options.
- Click the Advanced tab.
- In the Default Record Locking box,
click the option you want.
Yes, you can.
If the reports don't contain all the requirements you
expect, then there are two possible causes:
- You may have filtered out the missing requirements. Check
the Requirements Report Options to see which status codes are being
included.
- If certain fields are not set, then the requirement will
not appear in the report. This most often happens with imported data. Check that
the type, source, priority, and status are all set to values.
The fields included in the reports can be set from the
Options forms available from the Reports Switchboard.
If you are finding that your reports sometimes have blank
pages included, then unfortunately this is due to a bug in Microsoft Access
which changes the margin settings. Select Page Setup from the File
menu and change the left and right margins back to 15mm each.
If you have existing requirements that you wish to import to
WIBNI there are two ways of doing it:
- Place the requirements in an Excel or Lotus 1-2-3
spreadsheet and then on the File menu, point to Get External
Data, and then click Import. There is a Help page available on
how to arrange your data.
- (WIBNI 1.2 and later only) If your requirements are in
another WIBNI database, use the 'Import Database'
function on the Administration Switchboard
- Make backup copies of your 1.1 and 1.2 databases.
- Start the 1.1 database. There is one major difference
between 1.1 and 1.2 in terms of the data model: the Requirements ID has
changed from Text to an Integer. You have to change all your existing
requirement ids to integers in the 1.1 database before you can update.
Make sure you have not left any spaces or other non-integer characters
behind. Once you have done that, you can exit the 1.1 database.
- Start the 1.2 database. Select 'Administration' from the
main menu.
- Select 'Empty Database' to remove all the user and
configuration data.
- Select Tools from the pull-down menus, then Database
Utilities and Compact and Repair Database ... . This will
ensure all autonumbering will start from 1.
- Select 'Import Database' and use the file selector
to open your old 1.1 database.
- You should now have imported all the user data and
configuration from the old database.
The process of deletion is deliberately difficult on the
basis that unwanted requirements should be marked 'Rejected' rather than being
permanently deleted.
However, if you do wish to delete a requirement then you
need to know how to use Microsoft Access to delete records from tables. You
have to do the following:
- Make sure you delete any dependencies to other
requirements, business events or use cases by working through the relevant
tabs in the Requirements form.
- Select Window, Unhide ... and then the
wibni database in order to expose the Microsoft Access view on the
database.
- Open the History table and delete all the records that
contain the ID (in the RQ_ID field) of the requirement you wish to delete.
- Open the Requirements table and delete the relevant
record(s).
The process of deletion is deliberately difficult on the
basis that the history is supposed to provide an audit trail.
However, if you do wish to delete history items then you
need to know how to use Microsoft Access to delete records from tables. You
have to do the following:
- Select Window, Unhide ... and then the
wibni database in order to expose the Microsoft Access view on the
database.
- Open the History table and find the records that
contain the ID (in the RQ_ID field) of the requirement you are interested
in.
- Use the TransDate and NewValue fields to identify the
history items you want to remove.
- Select and delete the records.
