Functional Requirements are usually expressed as Narratives: stories, scenarios, Use Case Description Guidelines.

Non-technical customers might think of their system by imagining something happening with it, a story. After listing a few scenarios these can be reduced to a use case, i.e. a kind of workflow to accomplish a user task: scenarios are possible flows through the use case.

The workflow of a a Use Case can be modeled as a state machine, typically described by a UML state or activity diagram.

The system boundary defines which activities (functionality) is carried out by the system, and what is not: implication: what engineers must build.

Defining the system scope is a VERY important decision, there may be huge consequences if it is wrong.

• Fundamental questions:
  • What/who triggers the behaviour expected from the software?
  • Should we implement the requirements or is the requested functionality a responsibility of another system or a human?

We need to know the context in which a system operates

• External entities: other systems, organizations, people, machines, device (sensor, actuator), etc. that expect services/data from us or provide services to us
• Input/Output data flows from/to external entities

External entities that interact/interface withthe system are actors of use cases.