Page 55 - Software and Systems Requirements Engineering in Practice

28 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

• Artifact A rectangular box with the name of the artifact. The
definition of each artifact should be in a glossary or taxonomy
accompanying the model.
• Association A line connecting two artifacts. The line
indicates that there is a relationship between the artifacts.
Every association must be labeled to indicate the relationship
between the artifacts.
• Cardinality The cardinality indicates quantities. Any
numbering convention can be used if appropriately defined;
however, the Unified Modeling Language (UML) notation is
3
typically used. If the cardinality is not specified on an
association, then unity is implied.
Figure 2.7, showing a sample model fragment, can be read as
follows: “One or more actors participate in one or more use cases, and
an actor can initiate one or more use cases.”

Creation of a Requirements Engineering Artifact Model
The actual creation of an artifact model is not difficult. What is important
is to have a holistic understanding of the business processes used from
product creation through maintenance. It may be necessary to identify
an individual within an organization who can interact with stakeholders
across the different organizational units. Across the entire organization
and product life cycle, then, these questions must be asked:
• What are the artifacts that the roles use?
• How are the artifacts related?
• Who creates them?
• Who modifies them?
• How do they become obsolete?
Consider, as an example, a small company creating a software
product. They may have the following artifacts:
• Business plan
• Business goals
• Marketing brochure(s)
• Product features
• Customers
• Product definition
• Test plan

3 The UML specification can be found at www.omg.org.