WORK PRODUCT II

Work Products in RE

• A recorded intermediate or final result generated in a work process.
• Stored electronically as files, databases, or in RE tools.
• Represented in various ways:
  • Natural language
  • Template-based
  • Model-based
  • Drawings or prototypes

Role of Models in RE

• Natural language can be ambiguous.
• A model is an abstract representation of an existing part of reality or one to be created.
• Modeling requirements helps maintain an overview and provides insight into the requirements.

Properties of a Model

• Abstract representation of reality in a descriptive or prescriptive way.
• Reduces information to focus on relevant aspects.
• Suits a specific purpose.

Advantages & Disadvantages of Modeling vs. Natural Language

• Advantages
  • A picture is worth a thousand words.
  • Restricted syntax reduces potential ambiguities.
• Disadvantages
  • If multiple models are used, consistency among them is crucial.
  • Not always possible to record everything in the model or multiple models.

Applications of Requirements Models

• Function and Flow
• Structure and Data
• State and Behaviour
• The nature of the system being modified or built dictates the models to be used.

Modelling System Context: DFD (Data Flow Diagram)

• Key components:
  • Context Boundary: Defines the scope of the system.
  • System Boundary: Separates the system from its environment.
  • Terminators (sinks and sources): External entities that interact with the system (Users, other Systems, Customer, Printer).
  • Data Flow: Indicates the movement of data between components.
    • Example data flows: Order, customer data, Book ordering system, Print job, Order status, Book delivery status, Financial administration, etc.
  • System under consideration:
    • Represented as << system name >>

Modelling System Context: UML Use Case Diagram

• Use Case: An activity that the system performs, usually in response to a request by a user.
• Use cases define functional requirements.
• Analysts decompose the system into a set of use cases (functional decomposition).
• Name each use case using Verb-Noun.

Modelling Structure and Data with UML Class Diagram

• Class: Describes a set of (material or immaterial) objects that have a similar structure, behavior, and relationships.
  • Represented as [class name]
• Attribute: Describes a property of the class.
  • Expressed as a certain type that restricts the values that can be assigned to the attribute.
  • Represented as [attribute name]: [type]
• Association: Relates two classes to each other.
  • Represented as [name]
• Multiplicities: Define how many instances of the class at the corresponding association end can participate in the association to a given instance of the class at the other end of the association.
  • Where n umber umber (zero or one time)
    • 0..* (zero or more times)
    • 1..* (one or more times)
    • 7 (exactly seven times)
    • 1 (default value, exactly one time)

Modelling Function and Flow

• Various models are used for function and flow:
  • BPMN (Business Process Model and Notation)
  • UML use case diagram
  • UML activity diagram
  • UML sequence diagram
  • Data Flow Diagram
  • Domain story models (https://domainstorytelling.org/)

UML Activity Diagram: Notations

• Start node: Indicates the starting point of the activity diagram.
• Decision node: Branches the activity flow based on a guard. The outgoing alternatives should be labeled with a condition or guard expression. The guard must be true before the move to the appropriate flow.
  • Represented as [guard]
• Merge node: Brings together multiple flows that are not concurrent.
• End node: Indicates the end point of the activity flow. There can be multiple end nodes.
• Control flow termination: Ends the activity flow.
• Action/Activity: Represents the non-interruptible action of objects. An executable computation that results in a change in state of the system or the return of a result.
  • Represented as [name]
• Action or control flow: Illustrates the transitions from one action state to another (also called edges and paths).
• Synchronization bar: A fork node is used to split a single incoming flow into multiple concurrent flows. A join node joins multiple concurrent flows back into a single outgoing flow. The action following the join node is executed after all parallel actions have been executed.
  • A fork and join mode are used together and are therefore often referred to as synchronization.

UML Sequence Diagram

• Sequence diagram frame: Defines the boundaries of the scenario.
  • The frame contains the keyword "sd" (sequence diagram) and the name of the scenario, sd <name>
• Actor or object: Represents a role that collaborates in the interaction of the specific scenario.
  • Represented as <instance>:<actor>
• Lifeline: Represents the role in the interaction over a period of time.
• Activation: Indicates that the role is active in the interaction. A role is active when it is in control of the interaction or if processing a message from another role.
• Termination: Indicates the termination of the role within the interaction.

Modelling State and Behaviour: UML State diagram

• Initial state: The starting point of a state machine or a composite state.
• Final state: A special kind of state signifying that the enclosing region is completed.
• State: Governs the reaction of the state machine to events. In other words, it describes the behavior of the system remaining in the specific state.
  • Represented as [name]
• Transition: A switch from one state to another state. A switch to another state occurs when an (optional) triggering event occurs. The transition is (optionally) guarded by a condition. Only if the condition is "true" does the transition take effect. Multiple conditions can be required for a transition. During the transition, an (optional) activity is performed.
  • Represented as Event [condition/Activity

Glossaries

• Martin Glinz
• International
• IREB Requirements Engineering Board
• A Glossary of Requirements Engineering Terminology. Caution: This glossary is aligned to the CPRE Foundation Level syllabus 3.0 only!

Requirements Document Structures

• Frequently used documents:
  • Stakeholder requirements specification
  • User requirements specification
  • System requirements specification
  • Business requirements specification
  • Vision document
• Alternative:
  • Product backlog
  • Sprint backlog
  • Story map
  • Development process chosen
  • Project-type domain