Requirements Management

[apetosa]

I read the Requirements Management PDF on the EA site, and it was a very good overview of how RM is implemented in EA.

As a self-practice exercise, I will use EA to model a software application for a fictitious business. The model will revolve around the software application (to be developed) rather than creating a software application to meet a specific business need. However, I plan on keeping the fictitious business in mind during software development.

With respect to requirements management, aside from the standard function and non-functional requirements, I would like to model the following high-level requirements:

• Core business capabalities
• Stakeholder needs

Naturally, the "standard" functional & non-functional requirements will aggregate into these "top-level" topic areas.

Questions:

• Is it reasonable to create "Busines Core Capabilities" & "Stakeholder Needs" packages in a Requirements Model diagram?
• Is there a best practice for using the EA-extended Custom Diagram for Requireents Management?
• When using the "New Model from Pattern" wizard, why does selecting the Requirments Model result in a Requirements Model package that includes a "Custom" diagram? If I create a diagram directly, I would normally choose "Requirements" over "Custom".

Thank you in advance for your feedback.

[AndyJ]

Have you considered using Requirement Type to keep track of classes of requirements?

I define the requirement types (see Settings|General Types|Requirements) as follows:

NEED Something the Business wants to achieve.
STKR Stakeholder Request (a requirement that hasn't been fully identified yet)
FEAT Something that the system must do.
Constraint: something that modifies requirements, that needs to be tracked separately...

 

[apetosa]

Thanks for the reply, Andy.

Typing the requirements is a good idea, but I alluded to a requirements management modeling best practice regarding the packaging. Also, I am still curious as to why the EAExample model uses a "Custom" diagram versus a "Requirements" diagram in its sample requirements model.

Upon further thought, I am considering using the Feature element for the Business Core Capabilities & Stakeholder Needs requirements. I had considered this originally, but was dissuaded. Here's why. The EA help system defines the Feature element as follows:

A Feature is a small, granular function or characteristic expressed in client-valued terms as a satisfaction of a requirement; for example: 'context-sensitive Help', or 'ability to reverse-engineer VB.Net'.

...and then goes on to say...

Features are the primary requirements-gathering artifact of the Feature-Driven Design (FDD) methodology...

The latter sentence threw me off a bit, since I am not use an Agile development methodology for this sample project. FDD is used within such a methodology.

Then I took a look at "Software Requirements, 2nd Ed." (Karl E. Weigers), which states the following:

People often talk about product features. A feature is a set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective (p.11).

This appears to validate my original hunch to use the Feature element in EA. Also, it very conveniently aligns to the intended semantics of the Business Core Capabilities & Stakeholder Needs packages.

The EA help system goes on to say that one or more Features are traceable to one or more Requirements, and one ore more Use Cases are in turn traceable to one or more Features.

This seems to make sense, although some Requirements may be stated internally on given elements, in which case that traceability does not apply.

Any thoughts?

Thanks.

[beginner]

We had this "feature" discussion a while ago here at my customer. Finally I decided to simply cut it off. Developers still hover in their feature cloud. No definition of that. It's really a cloud. From architectural side we approached it by defining technical use cases. Then we couple these to business use cases. Features are a number of technical use cases where the number itself is somehow vague, though a bit coupled to the business use cases.

b.