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

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

Admin Tracs are up with grader access Trac Template available Link to past project for examples of deliverables email 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 <DruAnn_Thomas@hmc.edu> Blogs Piazza work space on 2nd floor

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

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

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!

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

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.

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.

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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 …

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

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

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.

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

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

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

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.

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

Requirements for games Management Marketing Game Designer … Users Software engineers

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”

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

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

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

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

Keep Responding to Schedule Phase 1...

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?

The End