| Re: FW: [epf-dev] system requirements |
Ronald,
This sounds more like a business rule than a system requirement. Although the system is supposed to implement this. We record these as business rules, since it is a rule that also lives outside of the IT context. These kinds of rules in our situation must be captured in a central place and are maintained separately from the IT process. This way we achieve reuse of this information without having to redefine these rules for every project. This approach fits product based companies best (financial etc).
With regards,
Ronald
From: epf-dev-bounces@xxxxxxxxxxx [mailto: epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ronaldo r
Sent: 05 June 2007 21:08
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] system requirements
Hi Jim,
we use conceptual model to get requirements such domain of informations.
When we put a entity as a class in our conceptual model, we can put some atributes and write the domain for that attributes.
Example: we put a entity named Customer with an attribute named age. We define in the constraints of age that the age must be between 18 and 70.
This kind of information will be used to test the system. It is a requirement, isn't it?
The example above is a a requirement? This kind of information should be in other place, rather than conceptual model? Some authors tell to not put in the uses case the attributes of the entities. What's the recomendation of OpenUP for this kind of requirement?On 6/5/07, Jim Ruehlin <jruehlin@xxxxxxxxxx> wrote:
Hi Ronaldo,
All the requirements are characterized as use cases (for functional
requirements) or supporting (for non-functional) requirements. Artifacts
like the glossary and conceptual model support the understanding of
requirements (as well as development), but are not considered
requirements by themselves. For example, the definition of a term doesn'
t indicate how the system must perform, or how it can be tested. But
that term may be used in the context of a requirement, which is written
to be unambiguous, testable, and understandable.
Artifacts like prototypes prove technology, get feedback from the
customer, etc. But they don't describe, in an unambiguous way, how the
final system should perform. For that you need some form of well written
statements that the stakeholders and development team can understand and
agree on. OpenUP uses use cases and supporting requirements to achieve
this. There are other methods of course, such as user stories or writing
a bunch of discrete requirements.
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax: 949.369.0720
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx ]
On Behalf Of "Ronaldo r" <ronaldorezende@xxxxxxxxx>
Sent: Tuesday, June 05, 2007 7:00 AM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] system requirements
The Supporting requirements concept mention that supporting requirements
+ use cases define the requirements of the system. This means that the
Glossary, conceptual model (entities in a class diagram) and Prototypes
doesn't define the requirements of the system? Why this other
requirements are out?
-----
Supporting requirements and Use Cases, together, define the requirements
of the system. These requirements support the features listed in the
Vision statement. Each requirement should support at least one feature,
and each feature should be supported by at least one to requirement
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev