1. I494: Designing and Developing an Information System
Week 5
September 23, 2013

2. Please sit together with your team today

3. Outline
Admin Task Management Estimation

4. Practice on Wednesday
Keep an eye on your about where to go on Wednesday!
Practice activities this week:
Start figuring out exactly what features/functionality your project will contain
Start gathering requirements!

5. Proposal Issues Vagueness about the problem or solution
Define both the problem and solution in order to establish scope.
Why are you choosing that particular technology?
If your system needs constant data, what is the source? Who will maintain that flow?
Feasibility

6. Upcoming Assignments Individual Team Formation Report
Due every Friday by 5pm until you are in a fully-formed team
Team Project Proposal
Due Tuesday, September 24th by 5pm
One submission per team
Team Project Research Report
Due Tuesday, October 1st by noon
Team Prioritized Feature List
Due Tuesday, October 8th by 5pm
Tomorrow!
Next Week

7. Research Paper Rubric
Research: 50% Style: 20% Risks: 10% Feasibility/Platform/Client/Business Case: 20%

8. Admin Potential Research Report Tactics:
Look at websites for similar technologies and create a matrix for features/cost/etc.
Research the topic in a traditional fashion.
Create a survey and gather data.
Do usability studies of existing products
Conduct focus groups

9. BEST Social Mixer
Win $100,000 or more to start your own Internet, software or technology business through the Building Entrepreneurs in Software and Technology (BEST) competition.
Come to the BEST social mixer to:
learn more about the competition
start planning how to best present your start-up company
meet other students who want to participate in the competition
find teammates to round out your team
 Friday, October 4 from 12 – 2 pm in the Informatics West Lobby
Pizza will be provided
 Please RSVP by completing this form by September 27:
 Learn more about BEST at

10. Requirements

11. Classic Waterfall The Problem Concept Requirements Design Construct
Test
Deploy

12. Classic Waterfall The Problem What we need to do to solve the problem
Concept
What we need to do to solve the problem
Requirements
Design
Construct
Test
Deploy

13. Classic Waterfall The Problem Concept
What we need to do to solve the problem
Requirements
How we will solve the problem
Design
Construct
Test
Deploy

14. Classic Waterfall The Problem Concept
What we need to do to solve the problem
Requirements
How we will solve the problem
Design
Build the solution
Construct
Test
Deploy

15. Classic Waterfall The Problem Concept
What we need to do to solve the problem
Requirements
How we will solve the problem
Design
Build the solution
Construct
Test
Deploy
Verify that we have solved the problem

16. Classic Waterfall The Problem Concept
What we need to do to solve the problem
Requirements
How we will solve the problem
Design
Build the solution
Construct
Test
Deploy
Verify that we have solved the problem
Problem solved

17. Classic Waterfall
Concept
Requirements
Design
Construct
Test
Deploy

18. What are Requirements?
“Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.”
-Sommerville and Sawyer, 1997

19. Exercise Think about your project.
As an individual without communicating with your teammates:
Take out a piece of paper and draw a picture of how you envision your project will look.
This can be:
A sketch of the website or interface
A diagram showing how the system works

20. Exercise Now as a project team: Compare your sketches. Notice
Are they similar? Different?

21. What Happens when…
…we try to build a new building without a blueprint?

22. What Happens when…
…we code an assignment before we think about how to do it?

23. Capstone Mantra
“Plan the work, then work the plan”

24. What are Requirements?
As complete a plan for building your system as it is feasible to create! More time spent gathering and specifying requirements results in much less time spent developing and testing % of all defects in software products can be directly attributed to errors in the requirements phase.

25. Types of Requirements Functional
Specifies the software functionality that must be built
“The system must…”
Often grouped around features
NonFunctional
Quality attributes
“user-friendly”
Constraints
Performance goals
Business rules

26. Requirements Business Requirements High-level objectives of the client
Why the system is being built
Vision and scope document
User Requirements
Defines user goals or tasks
Business rules
Not a software requirement per se, but impacts requirements
Regulations, policies, etc

27. Requirements
Qualitative vs Quantitative

28. Requirements Lifecycle
Elicitation
Analysis
Specification
Verification

29. Ways to Elicit Requirements

30. Ways to Elicit Requirements
Interviews Observation Study the “As is” situation Surveys Research Prototype Brainstorming

31. “ilities” Usability Maintainability Flexibility Testability
Scalability
Availability
Extensibility
Security
Portability
Compatibility
Backwards Compatibility
Interoperability
Reusability
Quality
Marketability
Configurability
Auditability

32. Kinds of Requirements Exciting Over the top ideas Regular
Standard ideas
Expected
Unstated ideas

33. Excellence in Requirements
What qualities should describe your requirements?

34. Excellence in Requirements
Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable

35. Complete Requirements
Fully describes functionality
Contains all information to design and build
Use placeholders (templates)
Example:
The system must capture customer information
The system must capture name, address, phone number and information for customers

36. Correct Requirements Strive for total accuracy
Users are critical in determining correctness

37. Feasible Requirements
Can it be built? Do you have the skills to build it?

38. Necessary Requirements
Actual need
Legal compliance
Traced to origin
Understand why functionality is required

39. Prioritized Requirements
Rank
High, medium low
Trace
How are functions related?
Provides flexibility for schedule adjustments, new requirements, etc.

40. Unambiguous Requirements
Two person test:
Randomly choose two people –
Do they agree on interpretation
Natural language can be problematic
Use the user’s language – not jargon
Define any specialized terms
Simple, concise, straightforward language

41. Verifiable Requirements
Develop test scenarios in advance

42. Exit Strategy
All projects need an exit strategy In other words, plan for completion Might be contractually defined

43. Version Management
Consider the lifecycle of the requirements Do you change them? Is there a document for each change? What about the schedule? Changes have ripple effects

44. Requirements Organization
How should we label the requirements
By name?
By number?
By category?

45. Strategy Work from high level to details
Use diagrams to communicate ideas
Build a dictionary
Users have a different language
Use html documents for navigation

46. Tool: Use Cases
Allows a team to elicit requirements by analyzing a sequence of interactions between a user role and the system. Objective is to describe all tasks that any user role will need to perform within the system.

47. Exercise: Use cases Think of Facebook In your project teams,
Identify 10 interactions a user might perform with the system.

48. Use Cases
Work from low level of detail to high level of detail Step 1: Number and Name Step 2: low detail Step 3: high detail

49. Example 1
An online order process

50. Step 1:
Use Case Number: 1.0 Use Case Name: Place Order

51. Step 2: “Casual” Use Case
Use Case Number: 1.0 Use Case Name: Place Order Use Case Description: After the user has selected items to order, the user will give payment information and shipping location. When the order is placed a confirmation will be given to the user. Some users will have existing accounts.

52. Step 3: Full Use Case
Use Case Number: 1.0 Use Case Name: Place Order Actors: Registered user Non-registered user Order system Billing system Triggers: The user is done shopping and indicates that they want to checkout. Precondition: User has selected items to purchase Post conditions: Order will be placed in system The user will have a confirmation

53. Step 3:
Use Case Number: 1.0 Use Case Name: Place Order Normal flow: 1: The user indicates they want to checkout 2: The order system will show previous billing and shipping information 3: The user confirms billing and shipping 4: The order system shows the total cost 5: The user confirms the order 6: The order system will provide details to the billing system 7: The billing system will verify payment information and report back approval status 8: The order system will provide an order confirmation Alternate flows: 3.A.1: The user enters alternate billing and/or shipping information 5.A.1: The user cancels the order 8.A.1: The order system will provide a disapproved order confirmation

54. Classroom Assessment
This is NOT graded!
Get out a piece of paper and take a few moments to write down the answer to the following question:
What was the muddiest or least clear point from today’s class for you?
Make sure you write your name on the paper and turn it in as you leave class.