Embed Size (px)
Citation preview
Requirements ModelingRequirements Modeling
Today:Today: How Can we specify Requirements in a
meaningful way
reqsModeling.f12.ppt
CS 121“Ordering Chaos”
“Mike” Michael A. Erlinger
– 2 – CS 121
AdministriviaAdministrivia
Teams chosen, GLECS assigned, mail lists madeTeams chosen, GLECS assigned, mail lists made
Tracs createdTracs created
svns createdsvns created
Elicitation done…Elicitation done…
– 3 – CS 121
AdminAdmin
Tracs are up with grader accessTracs are up with grader access
Trac Template availableTrac Template available
Link to past project for examples of deliverablesLink to past project for examples of deliverables
email lists for all teamsemail lists for all teams without graders without teachers
all teams should have contact info for teachersall teams should have contact info for teachers 2 conference rooms to reserve. check with DruAnn Thomas
Blogs Blogs
PiazzaPiazza
work space on 2work space on 2ndnd floor floor
– 4 – CS 121
Panic: Due within 7 DaysPanic: Due within 7 Days
Management UpdateManagement Update
Customer Elicitation ReportCustomer Elicitation Report
Game TreatmentGame Treatment
Use CasesUse Cases
Technology AssessmentTechnology Assessment
Forcing pyGame version to run on both Mac and PcForcing pyGame version to run on both Mac and Pc
– 5 – CS 121
Last lectureLast lecture
Good requirements are crucialGood requirements are crucial
Specifying requirements is hardSpecifying requirements is hard lots of examples of poor requirements
– 6 – CS 121
TodayToday
Modeling Requirements:Modeling Requirements:
from customer views to something translatable to from customer views to something translatable to softwaresoftware
Techniques for developing functional requirements
What the software is supposed to do!
– 7 – CS 121
Requirements modelingRequirements modeling
We build models in requirements analysis to We build models in requirements analysis to understandunderstand current systems or business processes which we are trying
to automate how users will use a new system
– 8 – CS 121
The software requirements documentThe software requirements documentThe software requirements document is the official The software requirements document is the official
statement of what is required of the system statement of what is required of the system developers.developers.
Should include both a definition of user requirements Should include both a definition of user requirements and a specification of the system requirements.and a specification of the system requirements.
It is NOT a design document. As far as possible, it It is NOT a design document. As far as possible, it should set WHAT the system should do rather than should set WHAT the system should do rather than HOW it should do it.HOW it should do it.
8
– 9 – CS 121
Agile methods and requirementsAgile methods and requirements
Many agile methods argue that producing a Many agile methods argue that producing a requirements document is a waste of time as requirements document is a waste of time as requirements change so quickly.requirements change so quickly.
The document is therefore always out of date.The document is therefore always out of date.
Methods such as XP use incremental requirements Methods such as XP use incremental requirements engineering and express requirements as engineering and express requirements as ‘‘user user storiesstories’’
This is practical for business systems and games but This is practical for business systems and games but problematic for systems that require a lot of pre-problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems delivery analysis (e.g. critical systems) or systems developed by several teams, e.g., large government developed by several teams, e.g., large government systems.systems.
9
– 10 – CS 121
Requirements document variabilityRequirements document variabilityInformation in requirements document depends on the Information in requirements document depends on the
type of system and the approach to development type of system and the approach to development used.used.
Systems developed incrementally will, typically, have Systems developed incrementally will, typically, have less detail in the requirements document.less detail in the requirements document.
Requirements documents standards have been Requirements documents standards have been designed e.g. IEEE standard. These are mostly designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems applicable to the requirements for large systems engineering projects.engineering projects.
Chapter 4 Requirements engineering
10
– 11 – CS 121
The structure of a requirements document 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.
11
– 12 – CS 121
The structure of a requirements document 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.
12
– 13 – CS 121
Requirements and DesignRequirements and Design
In principle, requirements should state what the system In principle, requirements should state what the system should do and the design should describe how it should do and the design should describe how it does this.does this.
In practice, requirements and design are inseparableIn 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 – CS 121
Requirements Engineering/Requirements Modeling Processes
Requirements Engineering/Requirements Modeling ProcessesThe processes used for RE/RM vary widely depending The processes used for RE/RM vary widely depending
on the application domain, the people involved and on the application domain, the people involved and the organisation developing the requirements.the organisation developing the requirements.
However, there are a number of generic activities However, there are a number of generic activities common to all processescommon to all processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.
In practice, RE/RM is an iterative activity in which these In practice, RE/RM is an iterative activity in which these processes are interleaved.processes are interleaved.
14
– 15 – CS 121
Tools for modeling requirementsTools for modeling requirements
Use Cases Use Cases – in late 70s, my advisor wrote a tech paper on – in late 70s, my advisor wrote a tech paper on how to do thishow to do this
State DiagramsState Diagrams
UI Mockups UI Mockups – standard process in DoD and auto industry – standard process in DoD and auto industry – (Not in my kitchen)– (Not in my kitchen)
StoryboardsStoryboards
PrototypesPrototypes
Example: TLB – Meetings and Arch/Design SpecificationsExample: TLB – Meetings and Arch/Design Specifications
Today building is set down to light switches, some Today building is set down to light switches, some things floating… white board vs black boardthings floating… white board vs black board
– 16 – CS 121
Functional Reqs:What should it do?Functional Reqs: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
– 17 – CS 121
Client
sell my beautiful jewelry
Customer of client
find a cool ring on sale
User-centric: What, not howDifficult to express
Functional Reqs: What should it do?Functional Reqs: What should it do?
– 18 – CS 121
Modeling functional ReqsModeling functional Reqs
Identify user classesIdentify user classes
Example:jewelry store ownerbuyer of jewelry
– 19 – CS 121
Modeling functional reqsModeling functional reqs
Identify user classesIdentify user classes
For each user class identify goalsFor each user class identify goals
Example Buyer:
search for itemplace an orderreturn an item
– 20 – CS 121
Modeling functional reqsModeling functional reqs
Identify user classesIdentify user classes
For each user class identify goalsFor each user class identify goals
For each user class/goalFor each user class/goal Describe how the user will use the system
– 21 – CS 121
ExampleExampleName: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Shipping dept.
Initiator: AliceInitiator: Alice
Scenario:Scenario:
1.1. Alice calls companyAlice calls company
2.2. Bob answers phoneBob answers phone
3.3. Alice says she wants to place an order from the Alice says she wants to place an order from the catalogue.catalogue.
4.4. Bob asks how the order will be paid.Bob asks how the order will be paid.
5.5. …… USE CASE
– 22 – CS 121
Forms of Use CasesForms of Use Cases
Casual – Casual – ““user storiesuser stories””
Fully dressed use cases – preconditions, post-Fully dressed use cases – preconditions, post-conditions, actors, stakeholders, etc.conditions, actors, stakeholders, etc.
…
these are cultural issuesbut in agile methods, less is more
– 23 – CS 121
Key aspects of Use CaseKey aspects of Use Case
NameName: what we call this use case: what we call this use case
ActorsActors: entities that interact with system (typically : entities that interact with system (typically people but also can be other systems)people but also can be other systems)
InitiatorInitiator: actor who initiates the use case: actor who initiates the use case
ScenarioScenario: sequence of steps users take and how : sequence of steps users take and how system respondssystem responds
– 24 – CS 121
Example: Main scenarioExample: Main scenario
Name: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: AliceInitiator: Alice
Scenario:Scenario:
1.1. Alice calls companyAlice calls company
2.2. Bob answers phoneBob answers phone
3.3. Alice says she wants to order item X.Alice says she wants to order item X.
4.4. Bob checks stockroom for availability.Bob checks stockroom for availability.
5.5. Stockroom says it is available.Stockroom says it is available.
6.6. ……
– 25 – CS 121
Main scenario with branchesMain scenario with branchesName: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: AliceInitiator: Alice
Scenario:Scenario:
1.1. Alice calls companyAlice calls company
2.2. Bob answers phoneBob answers phone
3.3. Alice says she want to order item D23 from page 5 the Alice says she want to order item D23 from page 5 the catalogue.catalogue.
4.4. Bob checks stockroom for availability.Bob checks stockroom for availability.
5.5. Stockroom says it is available.Stockroom says it is available.
5a. Stockroom says it is not available. See order out of stock item 5a. Stockroom says it is not available. See order out of stock item use case.use case.
6. ….6. ….Alternative path can be completed or refer to another use
case.
– 26 – CS 121
Use case developmentUse case development
Brainstorm to identify Use CasesBrainstorm to identify Use Cases
Validate/prioritize/ensure consistencyValidate/prioritize/ensure consistency
Elaborate high priority/complex use cases Elaborate high priority/complex use cases identify identify new Use Casesnew Use Cases
Repeat until _________________Repeat until _________________
Waterfall: until done – done keeps movingAgile: until good enough for now
– 27 – CS 121
Sequence Diagram - AlternativeSequence Diagram - Alternative
Alice: Customer
Bob: Sales rep Stockroom
call on phone
answers phone
wants to order
…
– 28 – CS 121
Example: Pac Man Use CasesExample: Pac Man Use Cases
Actor Goal/Title Priority
User Play game 1
User Initialize game 1
User View high scores 3
User Set level 3
User Pause game 2
User Exit game 2
User Save game 3
User Change Controls 4
User Play saved game 3
– 29 – CS 121
Elaborated Use CaseElaborated Use CasePlay gamePlay game::
1.1. User chooses User chooses ““Play GamePlay Game”” from main menu. from main menu.
2.2. Start level is displayed with player having 3 livesStart level is displayed with player having 3 lives
3.3. User moves Pac Man left, right, up, down – User moves Pac Man left, right, up, down – (point to other UC)(point to other UC)
4.4. Pac Man moves to empty space, return to step 3Pac Man moves to empty space, return to step 3
4.a. 4.a. Pac Man hits dot but not end of level, 50 points awarded, return to Pac Man hits dot but not end of level, 50 points awarded, return to step 3step 3
4.b.4.b. Pac Man hits dot and level ends, 50 points awarded and new level Pac Man hits dot and level ends, 50 points awarded and new level starts (see starts (see start new level use casestart new level use case))
4.c. Pac Man hits ghost (see 4.c. Pac Man hits ghost (see hits ghost use casehits ghost use case))
4.d. Pac Man hits a wall, can4.d. Pac Man hits a wall, can’’t move any further in that direction, returns t move any further in that direction, returns to step 3 with new constraintto step 3 with new constraint
etc.etc.
– 30 – CS 121
Refined Use CaseRefined Use Case
Play game:Play game:
1.1. User chooses User chooses ““Play GamePlay Game”” from main menu. from main menu.
2.2. Start level Start level displayeddisplayed with 3 lives and 0 score with 3 lives and 0 score
3.3. Play level (see separate use case)Play level (see separate use case)
4.4. Repeat 3 on successive levels until game overRepeat 3 on successive levels until game over
– 31 – CS 121
Refined Use Case (no UI spec)Refined Use Case (no UI spec)
Play game:Play game:
1.1. User chooses to play gameUser chooses to play game
2.2. First level starts with 3 lives and 0 scoreFirst level starts with 3 lives and 0 score
2.2. Play level (see separate use case)Play level (see separate use case)
3.3. Repeat 3 on successive levels until game overRepeat 3 on successive levels until game over
How do you refine a Use Case??Talk to user!!
– 32 – CS 121
Pac Man Use CasesPac Man Use CasesActor Goal Priority
User Play game 1
User Play level 1
User Initialize game 1
User View high scores 3
User Set level 3
User Pause game 2
User Exit game 2
User Save game 3
User Change Controls 4
User Play saved game 3
– 33 – CS 121
Agile method: goal stackAgile method: goal stack
highest priority, best modeled use case, e.g, Play UC
lowest priority, least modeled use case, e.g., store game history
prioritizeduse cases
– 34 – CS 121
Uses of use caseUses of use case
RequirementsRequirements: : Define functional requirements Expose business rules (constraints on behavior)
PlanningPlanning: Suggest an iterative strategy: Suggest an iterative strategy
DesignDesign: Validate design models, i.e., does design : Validate design models, i.e., does design provide for Use Caseprovide for Use Case
TestingTesting: Provide scenarios for validation testing: Provide scenarios for validation testing
– 35 – CS 121
Requirement QualityRequirement Quality
Specify what not howSpecify what not how
UnambiguousUnambiguous
TestableTestable
FeasibleFeasible
ConsistentConsistent
PrioritizedPrioritized
Traceable – Agile: back to requestorTraceable – Agile: back to requestor
Interative: back to a specification #Interative: back to a specification #
Agreed upon by customerAgreed upon by customer
How can Use Cases contribute to quality in functional requirements?
– 36 – CS 121
Tools for modeling (functional) requirementsTools for modeling (functional) requirementsUse CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
good for describing “flow”
– 37 – CS 121
State diagramsState diagrams
Moves to empty spot
Pac Man has n lives, score k
moves left, right, up,down
Hits ghost:Sound effect
n reduced by 1Lose level
n=0
n>0
Hits dot:Sound effect
k increased by 50k<MAX
Win level
Play level: initialize n=3 (#lives), k=0 (level score)
k<0
– 38 – CS 121
Tools for modeling (functional) requirementsTools for modeling (functional) requirementsUse CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
good for describing “flow”
Better for state machines
– 39 – CS 121
UI Mock UPUI 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 – CS 121
StoryboardsStoryboards
Good for communicating “look and feel” in addition to Good for communicating “look and feel” in addition to “flow”“flow” (again addressing non-functional requirements) (Indian Jones vs Casablanca movies) Missing in my GPS experience
– 41 – CS 121
Tools for modeling (functional) requirementsTools for modeling (functional) requirements
Use CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
these are special cases of prototypes
– 42 – CS 121
PrototypesPrototypes
Sample level with simplified art, minimal features
Use fast prototyping tools to clarify functionality, look and feel, etc.
– 43 – CS 121
Which model should you use?Which model should you use?
All that are appropriate!
Invent new ones as needed!
– 44 – CS 121
Requirements for gamesRequirements for games
Game Designer
Management
Marketing
Users
…
Software engineers
– 45 – CS 121
Top down game specificationTop down game specification
High conceptHigh concept
Competitive analysisCompetitive analysis
Main characterMain character
Game MechanicsGame Mechanics
Underlying modelsUnderlying models
Major featuresMajor features
Look and feelLook and feel
ScoringScoring
UIUI
etc.etc.
Traditional Game Design Document
“Game Bible”
– 46 – CS 121
Bottom up game specificationBottom up game specification
Use casesUse cases
State diagramsState diagrams
UI mock upsUI mock ups
StoryboardsStoryboards
PrototypesPrototypes
Make your vision “concrete”
Discover technical requirements:• Display sprite• Move sprite• Detect collision• etc.
Address feasibility
Suggest iterative design/developmentstrategy
– 47 – CS 121
Agile method: goal stackAgile method: goal stack
initial top goals – risks, proof of conceptinitial top goals – risks, proof of concept
movesprite
display sprite
level 0
prioritizeduse cases,
proofs of concept
proof of concept tounderstand feasibility
use case
– 48 – CS 121
Next TimeNext Time
Design practiceDesign practice
Reading/watchingReading/watching McConnell UML tutorial (several pages, do it all)
– 49 – CS 121
Comments on Phase 1 StartupComments on Phase 1 Startup
High level concept High level concept should be specified more as a brain storming of
ideas. high level concept conveys formality before requirements elicitation
Teacher contactTeacher contact Need name, school description, classroom
description, etc. earlier. Hard to think about game concept or questions with no knowledge of environment
– 50 – CS 121
Keep Responding to ScheduleKeep Responding to Schedule
Phase 1...Phase 1...
– 51 – CS 121
Sample questionsSample questions
Why do we want to classify users?Why do we want to classify users?
What are use cases? What are their benefits? What are use cases? What are their benefits? Shortcomings?Shortcomings?
What are key components to a use case?What are key components to a use case?
How can use cases be employed throughout the How can use cases be employed throughout the project?project?
What is a sequence diagram and when is it useful?What is a sequence diagram and when is it useful?
How does UI design fit into the requirements process?How does UI design fit into the requirements process?
Why do we use prototypes in the requirements Why do we use prototypes in the requirements process?process?
– 52 – CS 121
The EndThe End
