You can use the section on Business Rules for Supporting Requirements.
Ana On 6/5/07, Ronaldo r <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > phone: 760.505.3232 > > fax: 949.369.0720 > > > > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] > On Behalf Of "Ronaldo r" <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2007 7:00 AM > To: epf-dev@eclipse.org > 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@eclipse.org > https://dev.eclipse.org/mailman/listinfo/epf-dev > > _______________________________________________ > epf-dev mailing list > epf-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/epf-dev > > _______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev