Name & Description

[John McPherson]

Sometimes I build models with
– Requirement Name (always filled in)
– Requirement Description (sometimes filled in)

Where the requirement can easily be described in just the name, I would just use the name. Where the requirement is too long, or has paragraphed formatting, I use the name as a heading, and the requirement as the formal statement of requirement

e.g.

Name: “The system shall display the name and description as a single attribute”
(with no description)

vs

Name: “Display of Name and Description as a single attribute”
Description:
“The system shall display Name and Description in one cell as follows:
The name shall be displayed in the first paragraph and the description in the next paragraph…

”

Alternatively, I might write the formal requirement in the “Name” field, and provide some clarifying notes in the description field”

What I would like is to be able to produce is a table with a column that I might call “Requirement”. The attribute would be “Name and Description”. If only one were present (normally the Name) then that would display. If both were present, the Name would display first, and the Description would show in the next paragraph.

This would use space more efficiently than having separate columns for Name and Description, particularly if the Description was only used for a small percentage of a group of requirements.

I would like this feature in an “Attributes of Related Elements” table. It’s similar to the Name+Alias (Hyperlinked) Attribute you have made available. I would also like it as an additional attribute in an “Attributes of this Element” table.

Thanks

[eadocX Support]

Good idea.
It’ll be in the next build, sometime next week.
Just tried this, and it looks slightly odd: it’s hard to tell which is the ‘name’, and which the ‘notes’. Where there are notes to print, should the Name part be highlighted somehow?
e.g.
My Requirement
This requirement is really important

I don’t like adding fixed bits of formatting like this – for each person who likes it, another will hate it! – but I think it looks better. For now, I’ll leave it as you described.

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

[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!

[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!

[Author]

Posts