John McPherson

[John McPherson]

Thanks

There is definitely such a thing as software being too “helpful”

[John McPherson]

Hi

This is what I am aiming for:

The system shall allow users to display the Name and Description within the same cell of a table, while visually separating the actual requirement from explanatory notes.
Notes:
The reason for this requirement is that it is an efficient use of space. Having the name and description in different cells doesn’t look as good to me, and it takes more space. However, I like to make a clear distinction between what is the actual requirement, and what is just supporting information. If the “description” field is used for supporting information, I use a “Notes:” heading, formatted as above. I use the formatting available in EA to do this. When writing directly into the description field (in EA, after opening the properties pop-up window) I write “Notes:” at the top of the description, and use the EA formatting to format as above. I then write the actual notes as normal text. This approach gives me a clear distinction between the Requirement and the supporting information. If I wanted the description field to be a part of the formal requirement I would simply omit the “Notes:” heading.

I hope this helps. I would be happy to post some examples, in the new year, if requested. Kind Regards

[John McPherson]

Zip file now attached!

P.S. Not desperate for a fix/answer as I have a good workaround for my project

[John McPherson]

Thanks
I gave this a try and the paragraph breaks now appear. I have some new problems that are related.
1) The second and subsequent paragraphs are in a different format from the first
2) The first paragraph is in “Normal” format. I had expected all paragraphs to be in my own format, as specified in: Tools/Options and Settings/Inline text settings/Normal inline text style
See attached files for demo.

[John McPherson]

Thanks for the reply. Looks like v3.4 will help. Yes, I have thought about inline tables and may give that a try.

• This reply was modified 11 years ago by eadocX Support.

[John McPherson]

Hi. I’m using Word 2007 – I haven’t checked the build because problem solved. I put the Trace on it, and after a couple of tries everything worked perfectly. I think the fear of being watched must have scared the software into submission. I had a Windows update overnight (I’m running Windows 8) and I wonder if that had something to do with the fix. I had also had problems with eaXL (couldn’t create an Excel document) and that has magically fixed as well. Thanks for your response.

[John McPherson]

Thanks very much.

[John McPherson]

Thanks very much for doing this. I’ve started using the new functionality and it works exactly as expected. A big plus for your responsiveness!

[John McPherson]

Thanks for a great response!

About the formatting issue. It is a tricky one. Like you, I can see some benefits of using fixed formatting, but like the idea of leaving control of formatting to Word and the user.

I envisage using it several ways, all of which could be achieved without fixed formatting:

1)
The system shall oojah the widget (Name)

Note: As an implementation suggestion, the oojahrer system seems to be a good system to implement this requirement (Description. The modeller would write “Note: ” in the description i.e. I don’t expect eaDocX to insert “Note: “. In this case I would expect the reader to interpret the name as the formal requirement and the Note as suggestion/background that is not part of the formal “to be met” requirement)

2)
The system shall be very good. (Name)

By very good, we mean better than the old one, by a factor of 1.2. (Description. In this case I would expect the user to interpret the name and description combined as comprising the formal requirement)

3)
Combining Name and Description: (Name. As a modeller I might decide to put in first letter caps and a colon to provide the hint that this is a heading. I could also choose full caps. While this would look better in bold format, I think it’s workable without)

eaDocX shall provide the option of combining Name and Description as a single attribute. This shall be done by… (Description. In this case I expect the reader to interpret the name as a heading and the description as the formal statement of the requirement. The wording and the use of caps and colon, in the heading, provide the hints)

4) Variations on the above. e.g. writing “Note:” halfway through the description field.

In summary. I think the usage of the name and description fields provide enough information for the user to distinguish between headings, formal requirements, and notes/background, without fixed formatting. Another difficulty with fixed formatting is that only one of the above usages (3) would require it. The others work better without it(my view). Implementing without fixed formatting would meet my immediate need. Over to you!

Thanks for your thought and a commitment to implement in such a short time!

[Author]

Posts