LECTURE 2:

REQUIREMENTS –OR–
YOU WANT ME TO DO WHAT?
CSE 442/542 – Software Engineering
Change Happens
Bersoff’s “First Law”

No matter where you are in

developing a system
the system will change
& you will find
continued desire to change it
Why Changes Matter
Why Changes Matter
What Changes Matter

Changes
Changesinin
business
businessrequirements
requirements
Changes
Changesinin
technical
technicalrequirements
requirements
Changes
Changesinin
user
userrequirements
requirements other
documents

Project
data
Plan
Test Cases
code
Record Changes To
 Requirements
 Specifications
 Design Documents
 Source code
 Comments
 Test plans
 Test suites
 User & maintenance manuals
 Standards
What To Record For Change
 Properly handling change requires information:
 Track reason why change needed
 What was changed should be detailed
 For the changes, any side-effects important to note
 Detail of actual change should be tracked
 Anything useful when apportioning blame or praise
Function of Version Control

 Maintain integrity of your documents

 Limits who can commit changes to the system
 When committed, records who made each change
 Provides chance to link change to other documents
 Provides option to evaluate & control changes
 Run scripts before & after commits to system
 Changes creating bugs or defects can be rejected
 Notify project with each change & show the change
 Enable code to be regenerated post-commit
 Publish web pages containing the changes
Function of Version Control

 Maintain integrity of your documents

 Limits who can commit changes to the system
 When committed, records who made each change
 Provides chance to link change to other documents
 Provides option to evaluate & control changes
 Run scripts before & after commits to system
 Changes creating bugs or defects can be rejected
 Notify project with each change & show the change
 Enable code to be regenerated post-commit
 Publish web pages containing the changes
Baselines
 All documents in system at certain times
 Usually found when software could be released
 Further development based off of these baselines
 Important to have easy way to keep system stable
 Requires strictly limiting changes made to the system
 Ensures project ready for demos or release
 Method to roll system back to baseline needed
 Projects define strict change procedures
 Only acceptable changes allowed into system
Baselines
Deliverable Generation
 Need ability to recreate all SCIs
 Any release or time should be able to be recreated
 Version control can do easy part of rolling back code
 Tagging releases make this even easier
 May need old compilers, word processors, etc.
 Harder to maintain than code
 Even worse problem is maintaining hardware
 Linking software to hardware is also required
 What happens when hardware outdated?
It Came From the 70s…
Version Control Benefits
 Reduces effort managing & implementing change
 All changes can be placed in context
 Easier to see logic behind changes
 Software integrity and security increased
 Improves quality and reliability
 Fired worker cannot hold project hostage
 Generate information about process
 Improved process & team management
 Software development database automated
 Better finger pointing and/or saying “I told you so”
 What does git do for you?
 Version control AND source control
 Codebase and documents tracked and changes logged
 Can “revert” changes – go back to a working version
 Invisibly create branch in which riskier changes done
 Cannot overwrite changes by warning of merge conflicts
 Why git?
 Very popular; among most common systems used
 Likely to use this when working in industry
 Cannot be the price – open-source project is free
How Distributed VC Works…
git
 Created by Linus Torvalds for Linux development
 Need was great and so joined by many kernel developers
 Used by popular hosting services because of stability
 Since Linux changes are frequent, speed emphasized
 Name meaningless (Linus suggests multiple possibilities)

 Main repository hosted on remote server

 Users keep local copies into which only they commit
 Provides tolerance, since local changes do not pollute
 Allows local experiments, can fall back to remove copy
Scenario
Bob writes a bug just before a big release
 Result of this bug without good version control
 Bug gets into codebase since no way to catch it
 Client finds bug and complains about Bob
 Bob has a cold winter avoiding wolves in the outdoors
 Result of this bug with proper version control
 Bob tries to push bug from local to remote repo
 Push triggers checks and team member notices bug
 Remote repo reverted to before Bob’s mistake
 Program is not buggy & Bob keeps his job
git Structure
Connecting git Commands
 git init
 Creates a new repository & allows use as remote repo
 git clone
 Sets up a local repo be copy of (existing) remote repo
 git push
 Updates remote repo with saved local changes
 git pull
 Updates files with changes on remote repo
 Local changes guaranteed to not be overwritten
 Must complete before push command allowed to work
Pull often
 git pull requests can create merge conflicts
 Local & remote changes prevent automated merger
 Not just change to same file; must be on same line
 Do your best to avoid this; really painful to solve
 No easy solution – need to make changes manually
 Manual override needed for git to move forward

 Communication helps, BUT PULL EARLY AND

OFTEN!
Connecting git Commands
 git commit
 Saves all changes to local repo
 Process used to add files to local repo completed
 Does NOT touch remote repo; only local changed
 git add
 Prepares to add file to local repo
 Needs commit to complete this process
 Only local repo changed; does NOT touch remote repo
Commit messages
 Many different conventions
 All (but yours) sucks; choose who gets to complain
 Make messages meaningful and descriptive
 You will be thanked by your future self & contributors
 Critical for bigger projects since vital history of work
If You Have Too Much Time
git Branching
 Useful if adding feature, refactoring code,
debugging
 Want all benefits of version control as you develop code
 Once changes complete, need to push changes back
 Want any updates & limit conflicts for later push
 You half-completed code should not pollute colleagues

 git includes branching options for just these cases

 (As with most of this work, also true for other systems)
Without Branching
 Susan busy fixing backend of system
 Overhaul optimizes code & improves performance…
 … or it will once Susan completes this work
 May first make system unstable (or worse) until done
 Major task takes weeks, so pushes to avoid losing work
 John tinkering on frontend making cosmetic changes
 But gets Susan's code in pull & sees new side effects
 Assumes he caused changes and starts looking for bugs
 Experience is of bugs which appear & get fixed randomly
Without Branching
 Susan busy fixing backend of system
 Improves performance, but only once complete
 John tinkering on frontend making cosmetic changes
 Sees system and tries to associate his changes with bugs
Without Branching
 Huge argument about pushing incomplete code
 Most tempting & easiest solution reached: JUST WAIT
 Keep code local until complete so nobody else sees errors
 Works great in short term; John and Susan both happy
 Final work pushed & everyone is more productive
Without Branching
 Huge argument about pushing incomplete code
 Most tempting & easiest solution reached: JUST WAIT
 Keep code local until complete so nobody else sees errors
 Works great in short term; John and Susan both happy
 Final work pushed & everyone is more productive
Without Branching
 Huge argument about pushing incomplete code
 Most tempting & easiest solution reached: JUST WAIT
 Bad scenario: lose weeks of work with disk failure
Without Branching
 Huge argument about pushing incomplete code
 Most tempting & easiest solution reached: JUST WAIT
 Worse scenario: everyone pushes week of deadline
Without Branching
 Huge argument about pushing incomplete code
 Most tempting & easiest solution reached: JUST WAIT
 Worst scenario: everyone pushes day of deadline
Benefits of Branching
 Allows developers to work independently
 Changes and updates saved in version control
 Total independence not needed; others can join branch
 Always able to prune branch and rejoin rest of team
 Not everything is success, simplify if/when backing out
 Merge branch into master when work is complete
 Should not interfere with others; you got it working!
Benefits of Branching
 Allows developers to work independently
 Changes and updates saved in version control
 Total independence not needed; others can join branch
 Always able to prune branch and rejoin rest of team
 Not everything is success, simplify if/when backing out

 Merge branch into master when work is complete

 Should not interfere with others; you got it working!
Benefits of Branching
 Allows developers to work independently
 Changes and updates saved in version control
 Total independence not needed; others can join branch
 Always able to prune branch and rejoin rest of team
 Not everything is success, simplify if/when backing out

 Merge branch into master when work is complete

 Should not interfere with others; you got it working!
 Limits time solving conflicts (for most developers)
Branching in git
 git checkout –b <newBranchName>
 Creates new branch in repo named <newBranchName>
 Local system will now use branch (until merged back)

 Could instead use two separate commands:

 git branch <newBranchName>
 git checkout <newBranchName>
master and develop
 Two standard branches commonly used in git
 Default that & one initially used is master branch
 Often create develop branch for experimental code
 Only store code for stable releases in master
 Every version tagged so can always find where you were
 In worst case, always have solid, stable code available
 Never used directly; merges added after thorough testing
 Team keeps completed features in develop
 Code being readied for inclusion in next product release
 Gauge completion by testing develop for stability
master and develop
 When time to release new version draws near….
 Commits stored in develop merged into master
 master subjected to final tests for any latent bugs
 Once ready, add tag to identify version used in release
 …& repeat: continue work in develop for next pass
Standard Model for git
Developing Each Feature
 Between releases branch off develop not master
 Defines unit of code added back to project
 Selectively merging part of branch impossible
 Fine having many branches developed in parallel
 With branching cheap, often create one for each feature
Feature Key Point
 Between releases branch off develop not master
 Defines unit of code added back to project
 Selectively merging part of branch impossible
 Fine having many branches developed in parallel
 With branching cheap, often create one for each feature
Developing Each Feature
 Some, but not all, features work as expected
 Avoid confusion: delete branches where ideas failed
 Review code before merging into develop
 Or, & often done, just hope develop does not break
 master remains safe so still better than nothing
Merging: A Comparison

Merging With fast-forwarding Merging Without fast-forwarding

 Command to be used:  Command to be used:

git merge git merge --no-ff
 Changes merged &  Changes merged, but
branch existence lost branch existence kept
 git history complex  Branch development
from lack of data process can be seen
 Demands good  Helped by good
commit messages & commit messages &
useful tags useful tags
Merge History Comparison
Bugs (& Hotfixes) Happen
Picture of Good git Repo
Important Life Lessons
Listening to Your Clients
What Is a Requirement?
 From a popular trade book: “It’s a

specific thing
your system
has to do
to work correctly”
What’s the Problem?
 Often see moving target problem
 Requirements change immediately after creation
 Continue to change until project ends
 Stationary target difficult enough when coding
 Are all your programming assignments simple?
 Changing requirements complicate this even more
What’s the Problem?
 Often see moving target problem
 Requirements change immediately after creation
 Continue to change until project ends
 Stationary target difficult enough when coding
 Are all your programming assignments simple?
 Changing requirements complicate this even more

vs.
Why Do They Change?
 Requirement is contradictory or inaccurate
Why Do They Change?
 Requirement is contradictory or inaccurate
 “Want” v. “Need” conflated by clients at start
Why Do They Change?
 Requirement is contradictory or inaccurate
 “Want” v. “Need” conflated by clients at start
 Problems communicating with designers & coders
Why Do They Change?
 Requirement is contradictory or inaccurate
 “Want” v. “Need” conflated by clients at start
 Problems communicating with designers & coders
 Client changes their mind later on in the process
All Are Same Problem!

Communication
All Are Same Problem!

Communication
 Must ensure every detail is explicit
 Keep dictionary of important terms
 Result of each requirement clearly explained
All Are Same Problem!

Communication
 Must ensure every detail is explicit
 Keep dictionary of important terms
 Result of each requirement clearly explained

 Can you explain it to

Is It Really This Bad?
 Set of requirements must be meaningful to
 Client
Is It Really This Bad?
 Set of requirements must be meaningful to
 Client
 Designers
 Developers
Is It Really This Bad?
 Set of requirements must be meaningful to
 Client
 Designers
 Developers
 Users
Is It Really This Bad?
 Set of requirements must be meaningful to
 Client
 Designers
 Developers
 Users
 Legal
How To Do This?
 Stories are your hammer
 Provides insight into client’s goals
 Interactions specified & discussed
 Within story show cause-and-effect
 Testing script created for free
 People ♥ stories
 Document stories at multiple levels
 Visual, explanatory, outline important
How To Do This?
 Stories are your hammer
 Provides insight into client’s goals
 Interactions specified & discussed
 Within story show cause-and-effect
 Testing script created for free
 People ♥ stories
 Document stories at multiple levels
 Visual, explanatory, outline important

But what details should we include?

Too Much vs. Too Little

Too Much Too Little

Too Much vs. Too Little
 Doing nothing is losing, so do not even think it
 Limit use cases to highlight only important details
 WHAT & WHY, not HOW, included in these models
 Will still be able to find astonishing number of bugs
 Many details unusable or useless or both
 Including these would waste good web surfing time
 Clients do not understand or care about these details
 Fewer details == more time ogling “too little”
Too Much vs. Too Little
 Doing nothing is losing, so do not even think it
 Limit use cases to highlight only important details
 WHAT & WHY, not HOW, included in these models
 Will still be able to find astonishing number of bugs
 Many details unusable or useless or both
 Including these would waste good web surfing time
 Clients do not understand or care about these details
 Fewer details == more time ogling “too little”
User Stories to the Rescue
 Lightweight approach for capturing requirements
 Story documents single system interaction by user
 Details will change so does not waste time on them
 Needs fluctuate, so requirements readable by client
 Explains why requirement needed to allow prioritization
User Stories to the Rescue
 Lightweight approach for capturing requirements
 Story documents single system interaction by user
 Details will change so does not waste time on them
 Needs fluctuate, so requirements readable by client
 Explains why requirement needed to allow prioritization
 When change expected, can better use resources
 Cheap to create since user story often single sentence
 May never be implemented, so eschews most details
 Keeps focus on conversation rather than processes
 Waterfalls need not apply, common in iterative models
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“The gambler comes up

and places his bet.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“The gambler comes up

and places his bet.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“As a gambler,
I place my bet.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“As a gambler,
I place my bet.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“As a gambler,
I want to play blackjack
so I place my bet.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“As a gambler,
I want to play blackjack
so I place my bet
and get dealt a hand.”
User Story Basics
 Short statement of customer values and wants
 User’s view of feature described often in first person
 For each feature, explains why user wants/needs it
 Story should be testable: successful results shown
 Provides enough detail to create further client dialog
 Each story often a sentence, rarely more than two

“As a gambler,
I want to play blackjack
so I place my bet
and get dealt a hand.”
Be Wary of Details
“As a gambler,
I want to play blackjack
so I place my bet
and get dealt a hand.”
 How is a bet is placed?
 Possibilities include credit cards, chips, implantable IDs
 This may change, but does not affect the players desire
 Each story is part of a dialog may not be fully formed
 Negotiations on details occur when stories developed
 Many ideas never get coded, this avoids losing time
User Story Outline
“As a <role>,
I want <goal>
so I <action with testable result>.”
 Most common template used for user stories
 But these are stories, so templates not required/used
 Lots of roles exist among the users of a system
 Customer representative (or clients) present most ideas
 Others may exist: big betters expect special treatment
 Team brainstorm roles and see if stories might change
 Bring ideas back to conversation: client has final say
User Story Outline

As a <role>,
I want <goal>
so I <action with
testable result>.
Stories Are Writing
 Storytelling & writing are skills like any other
 Kids’ stories hard to follow and often have no point
 With age & lots of practice they will improve
Be Social!
Sprint Grading Part 1
 10 minutes: document ease of onboarding developer
 Project cannot stop for job changes (which do happen)
 Explain how repo allows newbie get up-to-speed quickly
 Progress on user stories & tasks associate with each
 Likely next steps based upon current state of tasks
 Simplicity of classes & commit message helpfulness

 Entire team helps present & answer questions

 Score shared by team & one-third of phase total
Sprint Grading Part 2
 10 minutes: demonstrate release from end of stage
 Must be in runnable state & stored on USB flash drive
 Demo machine chosen by me: should work anywhere
 Functionality added in sprint demonstrated & explained
 Continue ability to run past work identified & shown
 Show acceptance & unit tests pass using source code

 Entire team helps present & answer questions

 Score shared by team & one-third of phase total
Sprint Grading Part 3
 10 minutes: individual understanding of code
 Individually answer question on current implementation
 Fundamental to Scrum is collective ownership
 "I did not work on that" unacceptable response
 Having notes or using documents in repo encouraged
 Completeness of response is 26% of phase total
 Last 8% of phase grade uses average from rest of team

 Tell me EARLY when teammate not pulling weight

 Grade will not suffer because teammate unwilling