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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[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: [email protected] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
