1. Requirements Modeling
CS 121
“Ordering Chaos”
Requirements Modeling
“Mike”
Michael A. Erlinger
Today:
How Can we specify Requirements in a meaningful way
reqsModeling.f12.ppt

2. Administrivia
Teams chosen, GLECS assigned, mail lists made Tracs created svns created Elicitation done…

3. Admin Tracs are up with grader access Trac Template available
Link to past project for examples of deliverables
lists for all teams
without graders
without teachers
all teams should have contact info for teachers
2 conference rooms to reserve. check with DruAnn Thomas
Blogs
Piazza
work space on 2nd floor

4. Panic: Due within 7 Days
Management Update Customer Elicitation Report Game Treatment Use Cases Technology Assessment Forcing pyGame version to run on both Mac and Pc

5. Last lecture Good requirements are crucial
Specifying requirements is hard
lots of examples of poor requirements

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

7. 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

8. The software requirements document
The software requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements.
It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.

9. Agile methods and requirements
Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly. The document is therefore always out of date. Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ This is practical for business systems and games but problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams, e.g., large government systems.

10. Requirements document variability
Information in requirements document depends on the type of system and the approach to development used. Systems developed incrementally will, typically, have less detail in the requirements document. Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects.
Chapter 4 Requirements engineering

11. The structure of a requirements document
Chapter
Description
Preface
This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.
Introduction
This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.
Glossary
This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.
User requirements definition
Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.
System architecture
This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

12. The structure of a requirements document
Chapter
Description
System requirements specification
This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.
System models
This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models.
System evolution
This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.
Appendices
These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data.
Index
Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.

13. 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
A system architecture may be designed to structure the requirements;
The system may inter-operate with other systems that generate design requirements;
The use of a specific architecture to satisfy non-functional requirements may be a domain requirement.
This may be the consequence of a regulatory requirement.

14. Requirements Engineering/Requirements Modeling Processes
The processes used for RE/RM vary widely depending on the application domain, the people involved and the organisation developing the requirements.
However, there are a number of generic activities common to all processes
Requirements elicitation;
Requirements analysis;
Requirements validation;
Requirements management.
In practice, RE/RM is an iterative activity in which these processes are interleaved.

15. Tools for modeling requirements
Use Cases – in late 70s, my advisor wrote a tech paper on how to do this State Diagrams UI Mockups – standard process in DoD and auto industry – (Not in my kitchen) Storyboards Prototypes Example: TLB – Meetings and Arch/Design Specifications Today building is set down to light switches, some things floating… white board vs black board

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

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

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

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

20. Modeling functional reqs
Identify user classes
For each user class identify goals
For each user class/goal
Describe how the user will use the system

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

22. 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 …

23. 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

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

25. Main scenario with branches
Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: Alice
Scenario:
Alice calls company
Bob answers phone
Alice says she want to order item D23 from page 5 the catalogue.
Bob checks stockroom for availability.
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.

26. 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

27. Sequence Diagram - Alternative
Bob: Sales rep
Stockroom
Alice: Customer
call on phone
answers phone
wants to order …

28. Example: Pac Man Use Cases
Actor
Goal/Title
Priority
User
Play game 1
Initialize game
View high scores 3
Set level
Pause game 2
Exit game
Save game
Change Controls 4
Play saved game

29. Elaborated Use Case Play game:
User chooses “Play Game” from main menu.
Start level is displayed with player having 3 lives
User moves Pac Man left, right, up, down – (point to other UC)
Pac Man moves to empty space, return to step 3
4.a. Pac Man hits dot but not end of level, 50 points awarded, return to step 3
4.b. Pac Man hits dot and level ends, 50 points awarded and new level starts (see start new level use case)
4.c. Pac Man hits ghost (see hits ghost use case)
4.d. Pac Man hits a wall, can’t move any further in that direction, returns to step 3 with new constraint
etc.

30. Refined Use Case Play game: User chooses “Play Game” from main menu.
Start level displayed with 3 lives and 0 score
Play level (see separate use case)
Repeat 3 on successive levels until game over

31. Refined Use Case (no UI spec)
Play game:
User chooses to play game
First level starts with 3 lives and 0 score
Play level (see separate use case)
Repeat 3 on successive levels until game over
How do you refine a Use Case??
Talk to user!!

32. Pac Man Use Cases Actor Goal Priority User Play game 1 Play level
Initialize game
View high scores 3
Set level
Pause game 2
Exit game
Save game
Change Controls 4
Play saved game

33. Agile method: goal stack
highest priority, best modeled
use case, e.g, Play UC
prioritized
use cases
lowest priority, least modeled
use case, e.g., store game history

34. Uses of use case Requirements: Planning: Suggest an iterative strategy
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

35. How can Use Cases contribute to quality in functional requirements?
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?

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

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

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

39. 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

40. Storyboards
Good for communicating “look and feel” in addition to “flow”
(again addressing non-functional requirements)
(Indian Jones vs Casablanca movies)
Missing in my GPS experience

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

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

43. Which model should you use?
All that are appropriate!
Invent new ones as needed!

44. Requirements for games
Management
Marketing
Game Designer …
Users
Software engineers

45. Top down game specification
High concept Competitive analysis Main character Game Mechanics Underlying models Major features Look and feel Scoring UI etc.
Traditional
Game Design Document
“Game Bible”

46. Bottom up game specification
Use cases State diagrams UI mock ups Storyboards Prototypes
Make your vision “concrete”
Discover technical requirements:
Display sprite
Move sprite
Detect collision
etc.
Address feasibility
Suggest iterative design/development
strategy

47. Agile method: goal stack
initial top goals – risks, proof of concept
display
sprite
proof of concept to
understand feasibility
move
sprite
prioritized
use cases,
proofs of concept
level 0
use case

48. Next Time Design practice Reading/watching McConnell
UML tutorial (several pages, do it all)

49. Comments on Phase 1 Startup
High level concept
should be specified more as a brain storming of ideas. high level concept conveys formality before requirements elicitation
Teacher contact
Need name, school description, classroom description, etc. earlier. Hard to think about game concept or questions with no knowledge of environment

50. Keep Responding to Schedule
Phase 1...

51. Sample questions
Why do we want to classify users? What are use cases? What are their benefits? Shortcomings? What are key components to a use case? How can use cases be employed throughout the project? What is a sequence diagram and when is it useful? How does UI design fit into the requirements process? Why do we use prototypes in the requirements process?

52. The End