How are Requirements Organized in UP Artifacts? - UML

The UP offers several requirements artifacts. As with all UP artifacts, they are optional. Key ones include:

  • Use - Case Model :- A set of typical scenarios of using a system. There are primarily for functional (behavioral) requirements.

  • Supplementary Specification :- Basically, everything not in the use cases. This artifact is primarily for all non - functional requirements, such as performance or licensing. It is also the place to record functional featuresnot expressed (or expressible) as use cases; for example, a report generation.

  • Glossary :-In its simplest form, the Glossary defines noteworthy terms. It also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth. The Glossary can detail any element: an attribute of an object, a parameter of an operation call, a report layout, and so forth.

  • Vision :- Summarizes high - level requirements that are elaborated in the Use - Case Model and Supplementary Specification, and summarizes the business case for the project. A short executive overview document for quickly learning the project's big ideas.

  • Business Rules :- Business rules (also called Domain Rules) typically describe requirements or policies that transcend one software project they are required in the domain or business, and many applications may need to conform to them. An excellent example is government tax laws. Domain rule details may be recorded in the Supplementary Specification, but because they are usually more enduring and applicable than for one software project, placing them in a central Business Rules artifact (shared by all analysts of the company) makes for better reuse of the analysis effort.

What is the Correct Format for these Artifacts?

In the UP, all artifacts are information abstractions; they could be stored on Web pages (such as in a Wiki Web), wall posters, or any variation imaginable, The online RUP documentation product contains templates for the artifacts, but these are an optional aid, and can be ignored.

Does the Book Contain Examples of These Artifacts?

Yes! This book is primarily an introduction to OOA / D in an iterative process rather than requirements analysis, but exploring OOA / D without some example or context of the requirements gives an incomplete picture it ignores the influence of requirements on OOA / D. And it's simply useful to have a larger exampleof key UP requirements artifacts.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics