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

Please sit together with your team today

Outline Admin Task Management Estimation

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

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

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

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

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

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: http://bit.ly/12h2A4q.  Learn more about BEST at http://www.best.indiana.edu.

Requirements

Classic Waterfall The Problem Concept Requirements Design Construct Test Deploy

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

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

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

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

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

Classic Waterfall Concept Requirements Design Construct Test Deploy

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

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

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

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

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

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

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. 40-60% of all defects in software products can be directly attributed to errors in the requirements phase.

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

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

Requirements Qualitative vs Quantitative

Requirements Lifecycle Elicitation Analysis Specification Verification

Ways to Elicit Requirements

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

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

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

Excellence in Requirements What qualities should describe your requirements?

Excellence in Requirements Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable

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 email information for customers

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

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

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

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

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

Verifiable Requirements Develop test scenarios in advance

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

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

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

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

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.

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

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

Example 1 An online order process

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

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.

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

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

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.