contains all that is required to carry out software modeling

1. Requirements Modeling
Course code: SWE 2102
MBARARA UNIVERSITY OF SCIENCE AND
TECHNOLOGY
Course Facilitators: Dr. Angella Musiimenta
(PhD) & Wilson Tumuhimbise (MSc)
1

2. Today
Modeling Requirements:
from customer views to something translatable to
software
Techniques for developing functional requirements
What the software is supposed to do!

3. Requirements modeling
We build models in requirements analysis to
understand
current systems or business processes which we are trying to
automate
how users will use a new system

4. Building from the Requirements document
• Refer to the Requirements document
4

5. What is a model
• A representation of a system that allows for investigation
of the properties of the system and, in some cases,
prediction of future outcomes
5

6. Role of Modelling in RE
• Modelling can guide elicitation
– It can help you figure out what questions to ask
– It can help to surface hidden requirements
does it help you ask the right questions?
• Modelling can provide a measure of progress:
– Completeness of the models -> completeness of the elicitation
(?)
• i.e. if we’ve filled in all the pieces of the models, are we done?
6

7. Role of Modeling..
• Modelling can help to uncover problems
– Inconsistency in the models can reveal interesting things
• e.g. conflicting or infeasible requirements
• e.g. confusion over terminology, scope, etc
• disagreements between stakeholders
• Modelling can help us check our understanding
– Reason over the model to understand its consequences
– Provide views that allow us to understand product requirements
precisely.
• Does it have the properties we expect?
– Animate the model to help us visualize/validate the requirements
7

8. Example types of models
• Business model: describes the target environment and
processes. They describe why a product is needed
• A feature and/or goal model describes planned product
features. A goal model focuses on nonfunctional
requirement constraints. Describes the features of a
product being created to enable the business model.
8

9. Types of models…
• Use case/analysis model describes each product feature
in detail and contains the product requirements.
• The design model translates the requirements into a
product design. illustrates the architecture for the product.
9

10. Requirements and Design
In principle, requirements should state what the system
should do and the design should describe how it does
this.
In practice, requirements and design are inseparable

11. Tools for modeling requirements
• Use Cases
• State Diagrams
• UI Mockups – standard process in
Department of Defense and auto industry
• Storyboards
• Prototypes
• Example: TLB – Meetings and Arch/Design
Specifications

12. Functional Requirements:
What should it do?
Developer
connect mysql
database to asp
.net web …
Client
sell my
beautiful
jewelry
Customer of client
find a
cool ring
on sale

13. Client
sell my
beautiful
jewelry
Customer of client
find a
cool ring
on sale
User-centric: What, not how
Difficult to express
Functional Requirements:
What should it do?

14. Modeling functional Reqs
Identify user classes
Example:
jewelry store owner
buyer of jewelry

15. Modeling functional reqs
Identify user classes
For each user class identify goals
Example
Buyer:
search for item
place an order
return an item

16. Modeling functional requirements
Identify user classes
For each user class identify goals
For each user class/goal
Describe how the user will use the system

17. Example
Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob,
Stockroom, Shipping dept.
Initiator: Alice
Scenario:
1. Alice calls company
2. Bob answers phone
3. Alice says she wants to place an order
from the catalogue.
4. Bob asks how the order will be paid.
5. … USE CASE

18. Forms of Use Cases
• Casual – “user stories”
• Fully dressed use cases – preconditions, post-conditions,
actors, stakeholders, etc.
…
these are cultural issues
but in agile methods, less is more

19. Key aspects of Use Case
• Name: what we call this use case
• Actors: entities that interact with system
(typically people but also can be other
systems)
• Initiator: actor who initiates the use case
• Scenario: sequence of steps users take and
how system responds

20. Example: Main scenario
Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping
dept.
Initiator: Alice
Scenario:
1. Alice calls company
2. Bob answers phone
3. Alice says she wants to order item X.
4. Bob checks stockroom for availability.
5. Stockroom says it is available.
6. …

21. Main scenario with branches
Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: Alice
Scenario:
1. Alice calls company
2. Bob answers phone
3. Alice says she want to order item D23 from page 5 the catalogue.
4. Bob checks stockroom for availability.
5. Stockroom says it is available.
5a. Stockroom says it is not available. See order out of stock item use case.
6. ….
Alternative path can be completed or refer to another use
case.

22. Use case development
Brainstorm to identify Use Cases
Validate/prioritize/ensure consistency
Elaborate high priority/complex use cases  identify new
Use Cases
Repeat until _________________
Waterfall: until done – done keeps moving
Agile: until good enough for now

23. Example 2: ATM Use cases
23

24. Modeling scenarios using sequence diagrams
24

25. Use Case Elaborations
• A use case diagram by itself is useless. Each use case should be
associated with a use case elaboration. A use case elaboration
consists of the following information:
• Name:
Actors:
Description:
Priority: (high, medium, low)
Risk: (high, medium, low)
Scenarios:
Scenario 1: this is usually the main scenario
Scenario 2: an alternate scenario
Scenario 3: another alternate scenario
25

26. For example
• Name: Transfer Funds
Actors: Account Holder, Bank Server
Description: The account holder transfers a specified amount of
money from a specified source account to a specified destination
account.
Priority: high
Risk: medium
Scenarios:
Scenario 1: Funds are transferred successfully
Scenario 2: Insufficient funds in source account
Scenario 3: Source or destination accounts are in use
Scenario 4: Invalid PIN
26

27. Use Case Scenarios
• A use case scenario is a script that describes a typical
conversation between a use case and its associated
actors.
• The main scenario is the most typical conversation in
which the goal is achieved. Secondary scenarios describe
conversations in which errors or other unusual conditions
arise.
27

28. Modeling scenarios using scripts
• For example, the main scenario for "Transfer Funds" begins
by validating the account holder:
Holder: Inserts card
ATM: Reads card
ATM: Requests holder info
Bank: Returns holder info
ATM: Requests pin
Holder: Enters PIN
ATM: Validates PIN
ATM: Displays menu
28

29. Contd..
• Since the main scenario is usually successful, we may assume the
PIN was valid. Next the ATM gathers information from the holder
about the transaction:
Holder: Selects "Transfer"
ATM: Requests source account (Savings/Current)
Holder: Selects source account
ATM: Requests destination account
Holder: Selects destination account
ATM: Requests amount
holder: Specifies amount
ATM: Requests transfer
Bank: Transfers funds
Bank: Acknowledges transfer
29

30. Contd..
• Finally, the ATM acknowledges the transaction, prints a
receipt, and displays the options menu:
ATM: Acknowledges transaction
ATM: Need receipt?
holder: Selects "yes"
ATM: Prints receipt
ATM: Displays menu
30

31. Uses of use case
Requirements:
Define functional requirements
Expose business rules (constraints on behavior)
Planning: Suggest an iterative strategy
Design: Validate design models, i.e., does design provide
for Use Case
Testing: Provide scenarios for validation testing

32. Requirement Quality
• Specify what not how
• Unambiguous
• Testable
• Feasible
• Consistent
• Prioritized
• Traceable – Agile: back to requestor
Interative: back to a
specification #
• Agreed upon by customer
How can Use Cases contribute to quality in
functional requirements?

33. Tools for modeling (functional) requirements
• Use Cases
• State Diagrams
• UI Mockups
• Storyboards
• Prototypes
good for describing “flow”

34. State diagrams
• Describe the behavior of a system
• Help to visualize the entire life cycle of objects, provide a
better understanding of state based systems e.g a cash
machine
• Depict events effected by state transitions
34

35. State diagrams
Moves to
empty spot
Pac Man has n lives,
score k
moves left, right, up,
down
Hits ghost:
Sound effect
n reduced by 1
Lose level
n=0
n>0
Hits dot:
Sound effect
k increased by 50
k<MAX
Win level
Play level: initialize n=3 (#lives), k=0 (level score)
k<0

36. Tools for modeling (functional) requirements
• Use Cases
• State Diagrams
• UI Mockups
• Storyboards
• Prototypes
good for describing “flow”
Better for state machines

37. UI Mock UP
• UI Mock Up (or even full design) is often
considered part of the requirements process
because it summarizes the ways a user can interact
with the system.
• UI design can also address non functional
requirements, e.g., look and feel

38. Storyboards
Good for communicating “look and feel” in
addition to “flow”
– (again addressing non-functional requirements)

39. Tools for modeling (functional) requirements
• Use Cases
• State Diagrams
• UI Mockups
• Storyboards
• Prototypes
these are special cases of prototypes

40. Prototypes
Sample level with simplified art, minimal features
Use fast prototyping tools to clarify functionality, look and feel, etc.

41. Sample questions
• In requirements engineering, modelling customers’ views
to something translatable to software is critical. As a
software engineering student,
– Define the term requirements modelling.
– Explain any four roles of requirements modelling.
– Describe any five tools that can be used to model software
requirements.

42. Questions
42