Author Topic: Where to place detailed UI requirements?  (Read 1805 times)

DMT

  • EA User
  • **
  • Posts: 93
  • Karma: +0/-0
    • View Profile
Where to place detailed UI requirements?
« on: May 15, 2003, 01:49:17 pm »
I've just started using EA, and I'm really excited about using this tool to manage our complete set of requirements and analysis information. For the first half of our project (really the 1st of 2 subsystems), I used use cases to some degree, but the vast majority of functionality was described by simply placing a screen capture in the document and describing all of the behavior and interactions in the context of the on-screen controls.

Now, with the use of MANY more use cases, I can see that about 90% of what I was outlining in the "UI-centric" requirements documents can be captured in the use cases. However, there are some things that still seem like they need to be described elsewhere. Examples:

- "The Total Cost text box shall be read-only and shall appear with a background color that matches the form's color."
- Describing the shortcut keys for all of the controls.  I.e., pressing ALT-N will place the focus in the Name text box.
- "The category combo box shall have two columns. The first shall display the category abbreviation. The second shall display the category name. The list shall be sorted alphabetically by category name."
- "When the employee list is displayed, the Vacation Time column shall be blank for any employee row where the employee has been employed for less than six months."

I've seen someone suggest "View XXX" use cases to capture this sort of information. For example, "View Category Drop-Down List."  However, this seems to break the "don't couple your use case descriptions to exactly how the UI is designed" rule.

Does anyone have any practical advice on how to capture these nuances (which are typically down to the individual control level) using EA? I'm really dreading creating a separate UI spec that is external to EA, since I then lose the ability to cross-reference within EA.

darryl_staflund

  • EA User
  • **
  • Posts: 38
  • Karma: +0/-0
  • "mmmMMMmmm!!!   UML!"  -- Attributed to Homer
    • View Profile
Re: Where to place detailed UI requirements?
« Reply #1 on: May 15, 2003, 01:57:01 pm »
Hi there,

After looking the example EML model included with EA, I would probably do the following to capture UI requirements:

1.  Create a 'User Interface' logical model in much the same way as the example shows.

2.   For each UI component that makes up your model, I would open up its 'Properties' dialog box and then:

a.  Use the 'Responsibility' tab to enter display, function, testing, validation, performance, etc. information that the component is responsible for.

b.  Use the 'Constraints' tab to enter the constraints placed on the UI component by its immediate environment (i.e. allowable screen dimensions, corporate colour schemes, etc.)

c.  Enter other information as tagged attributes if appropriate.

3.  I would then establish 'realize' relationships between the UI component and its corresponding use case to maintain traceability between the two.

Cheers,
Darryl Staflund

DMT

  • EA User
  • **
  • Posts: 93
  • Karma: +0/-0
    • View Profile
Re: Where to place detailed UI requirements?
« Reply #2 on: May 15, 2003, 02:13:33 pm »
Hmmm.  That's a pretty good idea. My original documentation style actually used "classes" of controls to describe behavior.

What I could do is include control classes in a "UI Controls" package in my class diagram (since these "classes" need to be implemented as control classes anyway), and use objects instantiated from those classes in my UI specs.

I could put the "base" behavior into the UI control classes.

Since all of our UI is already laid out in Visual Studio, I could use aggregation in the UI diagram to show all of the controls the dialog or form uses. For each object, I can add functionality specific to that "instance" of the control.

This is a nice, clean OO solution that fits pretty well! Thanks!